This has no effect on the build, but some IDEs are only able to see and scan
headers referenced in CMakeLists.txt, so this fixes browsability for those IDEs.
clean up references to `__IMPORT__` and `__EXPORT__`
This removes any reference to the custom `__IMPORT__` and `__EXPORT__`
macros. These are remnants from supporting uwin. However, the need for
uwin is greatly diminished by proper native Windows support for the
library.
Furthermore, the functionality that this enables will be restored
imminently by means of decoration of public interfaces.
The uwin system used `_BLD_STATIC` to indicate a static build and
`__DYNAMIC__` to indicate a shared build. Furthermore, it used
`_BLD_DLL` to indicate a dynamic library on Windows, that is a DLL.
This augmented the check of `_DLL` which is the Microsoft specified
define that indicates a shared library build. Based upon the state of
these four flags (why four flags for 2 states?) it then defined
`__IMPORT__` and `__EXPORT__` to `__declspec(dllimport)` and
`__declspec(dllexport)` respectively.
To further complicate things, UWIN was built up during Windows 3.1,
which meant that it predated the linker support for DLL storage.
Instead, this is required work by the user, and it has special macros
for declaring the (now) synthetic import symbol as well as defining it.
This is now no longer required due to improved support in the compiler
and linker which will perform the necessary work.
On Unix, this synthetic symbol declaration and definition is not
required as the linker has always supported this for shared libraries -
it is responsible for creating the PLT which is roughly equivalent to
the IAT (technically, the IAT is both the PLT and the GOT). This is now
also automated on Windows, at least for the past ~25 years.
This clean up is meant to simplify the migration to `[module]_EXPORTS`
as the "standard" macro which is defined by CMake (and is generally used
elsewhere now as well) to indicate that the symbols for the module
should be exported. `_DLL` provides the necessary information whether a
DLL is being built or not.
With that history, it is clear that this is a regression for GraphViz on
uwin, the temporary breakage seems reasonable to simplify the migration.
This appears to have no effect, as C99 bools are not used anywhere in Smyrna or
in the headers included by viewport.h. However this is a trap waiting to cause
problems if/when C99 bools are used in these files.
This is a first step to moving away from PowerShell for CI scripts. PowerShell
has too many error prone characteristics and there is not enough knowledge about
it amongst the Graphviz maintainers.
Pylint has a very narrow idea of acceptable names. Things it does not like, such
as single letter variable names, are not really a problem in the Graphviz
scripts.
disable f-string in logging messages Pylint warning
This is generally considered error prone because you can include non-pure
operations in logging functions that your code accidentally depends on. However
the Graphviz scripts are simple enough that this is not a significant issue. The
use of f-strings pervasively makes for more consistent and readable scripts.
Remove the singular reference to `_BLD_stdio`. This is part of a series
to remove unused build macros to unify on the CMake standard `*_EXPORTS`
macros.
edgepaint: fix type of variable for interacting with getopt
Similar to 49fd8f62d8103d6e40a33922d2492a5ec3e3e76e, this location was using an
unsigned int for some reason. This change squashes a -Wsign-compare and a
-Wsign-conversion warning.
add a test case to keep .vcxproj and .vcxproj.filters sources in sync
Inspired by reviewing !1925, I realized there are few safeguards for those of us
editing the .vcxproj files while not on Windows. This commit introduces a basic
seatbelt to try to keep these files in sync. In future we could extend this to
check for file existence and other consistency.
This header is unused and does not need to be included. Although for
most uses this does not impact anything, attempting to use this in a
Swift program causes problems due to the library being pulled into a
modular build. This removal allows the use of xdot in Swift.
With the prior couple of changes, neither the Windows build nor the test suite
relies on a python3.exe binary. So we can simplify Windows CI by removing these
steps, leaving only a python.exe binary. This is more reflective of the typical
environment a user will have too. Related to #2049.
call Python as `python` instead of `python3` in MSBuild files
This removes an assumption from these files that Python 3 is available as
`python3`. On a Windows system, it is typically python.exe and users have to
create their own python3.exe if they want to call it under this name. Related to
#2049.
use CMake support to locate Python 3 before calling it
This change means (1) the CMake build system will fail less cryptically when
Python 3 is unavailable and (2) the CMake build system is now able to locate and
use Python 3 even when it is not called `python3`. Related to #2049.
remove test suite assumption that Python can be run as `python3`
On Windows, python3.exe does not typically exist. The python.exe binary is
Python 3 and is intended to be called as just this. The CI setup currently works
around this by copying python.exe to python3.exe. This change removes any
dependency on python3 existing, which should ease life for both CI and Windows
users wanting to run the test suite. Closes #2049.
build: use CMake to drive the position independence
This replaces the use of `-fPIC` with `CMAKE_POSITION_INDEPENDENT_CODE`
which is used by CMake to initialise the `POSITION_INDEPENDENT_CODE`
property on targets, which allows the portable way to indicate the
compiler-independent spelling for `-fPIC`. This was previously unset on
MSVC because MSVC does not support the `-fPIC` option and Windows by
default is PIC by means of the base relocation of the binary.
What kind of a warning is this? A class with even a single method isn’t a
mistake. It’s likely abstraction or indicating something semantic to the reader.
projects / graphviz / log