There’s been discussion about our build system in various unrelated topics and merge requests which we haven’t settled. I think it’s time to collect all ideas and opinions in one place, hence this topic.
References:
Continuing an email to @scnorth and @magjac…
Thanks for explaining, Stephen. The history was roughly what I had guessed.
However, my confusion isn’t so much about how the situation came about but rather why we’re continuing to (partially) maintain these three build systems in parallel. I’ll continue my stream of consciousness on the forum… Supported build systems going forward
My understanding is that we currently have the following:
- autotools - works on Linux, macOS, *BSDs, doesn’t work on Windows
- msbuild - only works on Windows, 64-bit builds don’t work
- CMake - partially works on Linux, Windows, doesn’t work on macOS
Presumably any user building from source only needs one of these, but they have no guidance on which one to select. They are stuck guessing and crossing their fingers.
I want to be clear, I’m not trying to complain about how we got here. I’m trying to make a case that we have at least one build system too many. Paring this back to 2 (or even 1, we can dream) would reduce our maintenance burden significantly.
I have my own personal feelings on the way forward, but I first want to get some consensus that we all agree Graphviz has too many existing build systems.
These are all very good threads and there are some especially important questions raised in the first one about what artifacts we want to deliver and what use cases we want to support. This would help show where the existing build configurations are soft and would clarify the amount of effort it would take to put the CMake configuration on par with autotools.
That said, there are some things that autotools won’t be able to deal with, e.g. non-unix packaging. I’ve made some headway on Windows packaging with CPack and I’d like to attempt that with OSX and Linux as well.
As I’ve been working on the project for a sum total of 72 hours, please excuse my presumption in using the term “we”. As always, a charitable interpretation would be appreciated 
The original authors are very inclusive and friendly, so that’s not a problem. Also, @smattr, @mark and myself (totally independently) joined the project just a few moths ago and became “we” almost immediately.
1 Like
A spurious discussion arose at
When reading Building with MinGW at Windows | Graphviz I get the impression that it would be possible on Windows.
I completely agree.
I don’t. Yet. I know too little about build systems in general and about the ideas behind and output of Graphviz’s current build systems in particular. I intend to research this better before I make up my mind. Before we decide to remove any build system, we must be know exactly what it provides and be sure that another build system can provide that instead so we don’t throw out the baby with the bathwater (I absolutely don’t mean this in any way as an objection to that you’re having personal feelings on the way forward 
, just that I am way behind you regarding build systems 
and haven’t acquired any feelings about it yet).
I definitely agree.
Yes, sorry for derailing that MR discussion somewhat.
Completely agree with this comment.
The main thing I want is group consensus that we should work to reduce the number of Graphviz build systems in the long term. I don’t believe this is a controversial point, but it seems we still haven’t unanimous agreement on this.
1 Like
No problem. That MR discussion will soon be forgotten 
. Or will it? Perhaps not quite. What will be forgotten is where we had it 
I would be supportive of moving to one build system.
I would also be supportive of keeping two build systems, if we had a good reason to, and if both were tested in CI so we know if we’ve broken one of them.
1 Like
I’m new here and don’t really have a vote (my opinion is of dubious weight…). I’ve been putting work into extending the CMake configuration because I understand it better than any of the other systems. I think it addresses a number of issues beyond what older build systems traditionally focus on, namely testing, packaging, and dependency management and it does seem to handle Windows well enough.
The number of technologies used in this project is daunting and it makes maintenance challenging. Having fewer systems and languages to understand would help keep focus. I’ve been trying to port autotools processes to CMake partly as proof of concept, partly to learn both systems, and partly so the CMake and autotools build processes can be compared fairly by people doing the heavy lifting on the actual application code. I have an opinion but it seems more appropriate (for now at least) to submit patches to the infrastructure to help others make a more informed decision.
1 Like
Another discussion arose at:
I’m not proposing this, but if the only thing we wanted to achieve was to get the Windows builds on par with the Linux ones, I think it would be worth a try to get the autotools build system to run on Windows.
I’m in favor of making the CMake build system the one and only build system long term since:
- We already have a good start.
-
CMakeis designed to be able to accommodate to many different OSs and we already now want to supportmacOSand perhaps later newer OSs on mobil devices, e.g.Android. - It will be easier to get contributions from people if we use
CMakethat anything else. - It’s more future-proof. Even if something better will come, a lot of people will know how to adapt
CMaketo it or maybe even auto-convert. If we stick withautotoolsit will be much harder to get help converting that later. - Moving to
CMakesignals to the community that Graphviz is to be relied upon even in the future.
The only thing I can think of that would prevent us from moving towards CMake only is if there already now exits something even better that the C/C++ community has converged upon instead of CMake. Since I don’t (yet) belong to that community, I wouldn’t know.
1 Like
As far as I’m aware, CMake is the dominant contemporary solution for C/C++.
1 Like