This is essentially a question for the other maintainers, but I saw no reason to have this discussion in private, so posting it to the public “Help” topic.
I don’t deal with the Windows builds/releases, so I regularly forget what the status quo is there and I’m surprised when I rediscover it. We currently have the following CI tasks for Windows:
32-bit CMake debug
32-bit CMake release
64-bit CMake debug
64-bit CMake release
32-bit MSBuild debug
32-bit MSBuild release
I have the following questions:
Why are there no 64-bit MSBuild tasks? I’m sure someone has explained this to me before, but I can’t remember why and can’t locate the relevant issue(s) with the explanation. If it’s explained on Gitlab, could someone drop a pointer to the relevant issue?
The mixture of debug and release ZIPs hosted on graphviz.org don’t seem consistent to me. Is this intentional? Here’s what I’m seeing:
We only host the latest stable release because we don’t have disk space for all of them. The 2.38 release was a manual mistake by me and I’ve now removed it. It and other old Windows releases are instead found at Index of /Archive/stable/windows.
It’s very well known and documented at New simplified installation procedure on Windows, but there’s no issue on it that I’m aware of.
I was under the impression that we didn’t want to put too much effort into the MSBuild version anyway and wanted to work as much as possible on the CMake version instead. From discussion in that GitHub issue is seems that MSBuild was a dead end anyway. Of course we could have an issue nevertheless, but I doubt it would ever get resolved.
I don’t understand how that would make any difference, but yes, I think that whoever supplied that package just wrapped ours. In general I think that’s how Chocolatey packages work, but perhaps someone else knows this better than me?
Just returning to this now, and I realize this is not quite correct. The URL you’ve quoted has a range of releases up to 2.38. Where are the releases in-between 2.38 and 2.44.1? E.g. where is 2.42?
Something related but minor: I think we should remove the directory hierarchy users have to jump through to download the Windows installers. Let’s change the “Stable Windows install packages” link on Download | Graphviz to a heading with three bulleted items underneath linking to each installer:
I don’t think any users are interested in the directory hierarchy or the incomplete 32-bit CMake release build. What do you think?
Failing that we could just dump the current release in the archive folder, Index of /Archive/stable/windows, along with everything else. This is basically what GNU does for all their tools already.
I meant 2.38 and older. We don’t save newer old releases any more.
The directory structure is what it is because I wanted to mimic the Linux releases as far as possible, but we can change that if you want. The CMake releases contain an .exe installer, while the MSBuilds don’t. I think most 32-bit users would prefer to use the CMake installer. That said, I’m okay with adding a bulleted list to the downloads page. I think many users need some guidance though. That’s why I wrote New simplified installation procedure on Windows.
Ah OK, I was not aware of this. Does this have any impact on package managers like Chocolatey that pull the installer? Do Chocolatey users ever request installation of a version prior to the current?
I don’t object to the installation procedures, and thank you for writing such a thorough document on this. However, what I’m questioning is that the current “Stable Windows install packages” link goes to a directory four levels above the actual files. From your description above, there will only ever be four files below this root as we’re not preserving past releases. So a Windows user has to click four times to reach a leaf directory containing a single file and then a fifth time to download the file. Could we not just skip the hierarchy and link directly to the leaf files?
I’m not sure which Linux releases you’re referring to, as all the Linux links on that page seem to go to external distro pages.
In case I wasn’t clear, I meant preserve the same directory hierarchy in terms of where the files are stored, but just have links on the download page that go straight to the files.
Actually there are/will be six files under stable and another six under development since we started deploying also the CMake Debug builds after the latest release. I will update New simplified installation procedure on Windows to reflect this.
Absolutely. I’m in favor of that.
Ah, I see. I misread. I was referring to the actual directory structure which is similar for Linux and Windows.
Why are we deploying both MSBuild and CMake installers? I understand where we the maintainers are at, but what decision is a user meant to make here? I.e. if I’m a user and I see a 32-bit debug MSBuild installer and a 32-bit debug CMake installer, how am I supposed to choose between them?
IMHO the build system chaos should not be exposed to users and we should simply be offering four installers:
The MSBuild builds are more complete in terms of functionality, but don’t come with an installer, contain no header files and perhaps have other shortcomings. I’ve seen issues where users install both of them on top of each other to compensate for this.
I don’t know. I feel like a user myself in that sense. If we knew the exact differences between them, mabye we could make better recommendations. I’m planning to do a more detailed investigation of this and present it in a way that will be useful for us when we try to make the CMake builds:
More complete than the MSBuilds so we can stop building using MSBuild.
As complete as version 2.38 so we can encourage downstream package managers to upgrade.
That seems reasonable from an outside perspective, but whichever 32-bit build we chose to expose will lack things that the one we don’t expose has.
Wow, this is some truly bizarre behavior that we’ve managed to train users into thinking is normal.
Should I shelve some of my other work and focus on aligning the two builds and/or fixing the CMake build? I did not fully grasp the scope of the dire situation Windows builds are in.
I’d certainly enjoy your company on the dark side. I’m pretty sick of Windows weirdness. ATM, I’ve left it though and rebooted in Linux mode trying to learn the code base by debugging Segmentation fault when running test example neatopack.c (#1800) · Issues · graphviz / graphviz · GitLab. I think you should finish what you are doing first. Personally I don’t like context switching too much. Also, even though the state of the Windows builds is not optimal, the lion part of users just want to run dot which is possible using any of them.
. This needs to be further investigated.