We have three flavors of Windows: native, MinGW and Cygwin. The two last have established package managers. Native does not. I think. Or have many partial. IDK. Matt can probably elaborate. Native Windows is a mess.
Although I set up most of the Windows build jobs originally because I was the only maintainer with a Windows machine, I know almost nothing about Windows and extremely little about package managers in general. The separate Windows dependencies repo was inherited from an earlier maintainer, but I introduced vcpkg to update it because it seemed like a good idea at the time. . Maybe it was. Maybe it wasn’t. It’s used by native Windows only and unrelated to MinGW/MSYS2/pacman.
Ideally (maybe?) we should use Docker also for Windows. I tried that six years ago to no avail.
FWIW I build most of GraphViz using vcpkg dependencies exclusivly (not windows, but for wasm) - I could take a look at a complete build targetting windows if I get chance?
Personally I am looking into what it would take to remove the Windows dependencies submodule entirely and install dependencies from vcpkg at build time. This would make updating dependencies a one-line config change in future. But I suspect I will run into the same barrier Magnus has hit in the past: Windows CI time limits.
It is worth mentioning that for other c++ projects I work on which uses vcpkg - we use it to build for all OSs not just windows (OSX and 'nix). While this goes against the grain for linux setups it does allow us to ship a universal package with all deps targetting a specific glibc version which will work on all 'nix variants that support that version of glibc…
I think @smattr 's approach (to remove dependencies from our tree) is the right one. The specific vulnerability that triggered this thread is irrelevant (the Tukaaani vulnerability doesn’t impact windows machines IIUC), but we do need a low effort (ideally zero effort) way to keep our builds up to date.
Checking in pre-compiled binaries of dependencies is almost as scary as shipping old versions with known issues.
Agree that eliminating our graphviz-specific dependency tree (with binaries checked in) is definitely preferable.
The problem with gitlab windows runner timeouts seems really bad.
One notes that it’s alleged to be possible to download and run the gitlab windows CI environment locally via node.js (npm install -g gitlab-ci-local, then gitlab-ci-local ) for prototyping and some testing. Also alleged to be possible to install a local CI runner and configure the gitlab project to use it, but seems more involved probably with a lot more ways to go wrong.
Builds cleanly on windows (I updated the developers.md with the instructions), it currently has the following missing optional deps:
ANN
GTK2
GD
GS
AA
SWIG
GUILE
JAVASCRIPTCORE
PerlLibs
PHP
Ruby
Note: As vcpkg builds all dependencies from source it is very slow (but it does a good job at caching the built assets, so a subsequent clean build will reuse those assets).
Thank you for doing this. I’m relying on @smattr for oversight and wisdom here, but I’d say we need at least some of the missing libraries (libgd for basic image generation, libANN which is problematic but enables overlap removal in neato, gs (ghostscript) is a beast but allows loading external images for shapes, might be needed for PDF?) though one notes that Magnus Jacobsson / graphviz-windows-dependencies · GitLab does not have gs.
Looking at the pipeline, it appears this MR breaks the Linux builds?
. Maybe it was. Maybe it wasn’t. It’s used by native Windows only and unrelated to MinGW/MSYS2/pacman.