fix: exclude cmd/smyrna when Smyrna is disabled during build
Similar to the situation just fixed with Lefty, when Smyrna was disabled
(`--with-smyrna=no` passed to the build system), several Smyrna related
artifacts would still be built and installed. We now exclude the entire Smyrna
subdirectory, which should be less error prone.
fix: exclude cmd/lefty when Lefty is disabled during build
When Lefty was disabled (`--enable-lefty` not passed to the build system),
several Lefty related artifacts would still be built and installed. E.g. the man
page. We now exclude the entire Lefty subdirectory, which should be less error
prone.
enable persistent Chocolatey cache in Windows CI jobs
The intention of this change is to accelerate Windows CI jobs, currently one of
the limiting factors on our CI throughput. This change takes a conservative
approach, giving each relevant job its own cache. In theory these jobs could all
share a cache, but the Gitlab docs¹ imply this is only safe if only a single job
has a `push` policy. To do this effectively, we would probably have to create a
new preliminary CI job that only built the cache. Then all other jobs would
become `pull` consumers of this cache. Perhaps an improvement to make in future.
do not create packaging hierarchy directory for architecture
The packaging directories were created based on various dimensions of a matrix,
with architecture at the lowest level. On Linux and macOS, Graphviz is only
packaged for a single architecture (x86-64). On Windows, Graphviz is only
packaged for two architectures (x86 and x86-64). However, the architecture is
also present in the suffix of every packaged file. E.g.
So there is no ambiguity if we drop the architecture directory. This seems to be
a case of YAGNI¹ where the system was setup to accommodate multiple
architectures but this has not been needed. We remove it now to (1) reduce
complexity and (2) have less verbose release filenames.²
Closes #2149.
¹ https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
² Example of a current verbose release filename,
stable_windows_10_cmake_Release_Win32_graphviz-install-2.49.3-win32.exe
Upcoming changes will add references to functions that are in libgvc. Note that
no changes are required to the MSBuild build system because it already links
Smyrna against libgvc.
gvconfig_libdir: fix const-correctness of char pointers in macOS code
Commit 284df35236e258a49b86fad6f0d062bf0c2fa840 changed the source pointer `tmp`
used here to be `const`. A side effect of this was introducing a warning
breaking the CMake build on macOS:
lib/gvc/gvconfig.c:329:10: error: initializing 'char *' with an expression of
type 'const char *' discards qualifiers
[-Werror,-Wincompatible-pointer-types-discards-qualifiers]
char* s = tmp-1;
^ ~~~~~
This commit was merged via !2231 whose source branch did not have permission to
use the macOS shared runners, so this issue was not caught in pre-merge CI.
A build system should not rely on the existence of 3rd party
library/header files in standard prefixes as one might want to compile
and link against a patched build or a custom install in some
non-standard location. This is also helpful for developers who rely on
package managers like Conda or Spack for their daily development.
If expat is a dep, we need to pass -I/path/containing/expat.h to the
compiler while compiling the source files of the target 'common_obj',
without which, one can face the following issue:
graphviz/lib/common/htmllex.c:28:10: fatal error: expat.h: No such file or directory
28 | #include <expat.h>
| ^~~~~~~~~
compilation terminated.
remove leading debian/changelog entries related to unreleased versions
As far as I can tell, this style of specifying `(@VERSION@-1)` as the Debian
package version is intended to allow the CI work flow to install an unreleased
DEB file. This works but:
1. The current list uses this identifier twice. Presumably commit 57337e45d04ceecc3273f7f0d9e6a2440f8128cb made a mistake in introducing a
new version instead of appending the changelog entry to the existing
(pending) top entry. The result is that any attempt to use this changelog
for actual packaging would be rejected due to two changelog sections for
the same version.
2. The Ubuntu Intrepid (8.10) package search functionality appears to have
been lost to the sands of time, but all recent Graphviz Ubuntu and Debian
packages have been produced by third-party volunteers external to Graphviz.
The two leading entries gave the false impression that recent Graphviz
Debian/Ubuntu packages are actually produced here. To avoid this going
forwards we retarget this to Bionic (the lowest version of Ubuntu we
support) and add an artificial entry indicating this is not meant to be
released.
3. There have been numerous changes in the era of these top two entries as
well as more recently. It is not clear to me why these two changes were
singled out for the changelog. Running the Debian packaging flow resulted
in a changelog indicating these two items are the only changes between
2.18-1ubuntu5 and 2.49.3.
Ben Hansell [Mon, 18 Oct 2021 17:02:46 +0000 (17:02 +0000)]
lib/common: add character width lookup tables for more fonts and variants
This allows Graphviz to estimate the widths of text spans more accurately when built without a textlayout plugin. The textlayout plugins are platform-specific and can be difficult to build for obscure platforms (e.g. Graphviz Online), resulting in node labels not fitting within their nodes nicely.
lib/common: add new source file and header
lib/common: don't install new header
lib/common: redesign hard-coded font metrics
lib/common: remove unused variables
lib/common: format new source file with clang-format
lib/common: add more fonts
lib/common: add warning spam guards
lib/common: improve code style and comments
lib/common: improve code style and comments
lib/common: fix const compiler error
lib/common: reuse existing isalpha_no_locale function
lib/common: fix another const compilation error
lib/common: fix yet another const compilation error
projects / graphviz / log