What are the differences between Autotools, Cmake and Scons?

Question

What are the differences between Autotools, Cmake and Scons?

Pentathlon

This topic is already discussed in Scons wiki. I suggest that you visit the following links: 1. scons.org/wiki/SconsVsOtherBuildTools Have you visited a very similar discussion thread in Ubuntu Forum? – Sclaff

You can check this pdf www-alt.gsi.de/documents/DOC-2007-Sep-17-1.pdf ; it has pros and cons and also some details about each tool. – Defense

Answer 1

In truth, Autotools' only real 'saving grace' is that it is what all the GNU projects are largely using.

Issues with Autotools:

• Truly ARCANE m4 macro syntax combined with verbose, twisted shell scripting for tests for "compatibility", etc.
• If you're not paying attention, you will mess up cross-compilation ability (It should clearly be noted that Nokia came up with Scratchbox/Scratchbox2 to side-step highly broken Autotools build setups for Maemo/Meego.) If you, for any reason, have fixed, static paths in your tests, you're going to break cross-compile support because it won't honor your sysroot specification and it'll pull stuff from out of your host system. If you break cross-compile support, it renders your code unusable for things like OpenEmbedded and makes it "fun" for distributions trying to build their releases on a cross-compiler instead of on target.
• Does a HUGE amount of testing for problems with ancient, broken compilers that NOBODY currently uses with pretty much anything production in this day and age. Unless you're building something like glibc, libstdc++, or GCC on a truly ancient version of Solaris, AIX, or the like, the tests are a waste of time and are a source for many, many potential breakages of things like mentioned above.
• It is pretty much a painful experience to get an Autotools setup to build usable code for a Windows system. (While I've little use for Windows, it is a serious concern if you're developing purportedly cross-platform code.)
• When it breaks, you're going to spend HOURS chasing your tail trying to sort out the things that whomever wrote the scripting got wrong to sort out your build (In fact, this is what I'm trying to do (or, rather, rip out Autotools completely- I doubt there's enough time in the rest of this month to sort the mess out...) for work right now as I'm typing this. Apache Thrift has one of those BROKEN build systems that won't cross-compile.)
• The "normal" users are actually NOT going to just do "./configure; make"- for many things, they're going to be pulling a package provided by someone, like out of a PPA, or their distribution vendor. "Normal" users aren't devs and aren't grabbing tarballs in many cases. That's snobbery on everyone's part for presuming that is going to be the case there. The typical users for tarballs are devs doing things, so they're going to get slammed with the brokenness if it's there.

It works...most of the time...is all you can say about Autotools. It's a system that solves several problems that only really concerns the GNU project...for their base, core toolchain code. (Edit (05/24/2014): It should be noted that this type of concern is a potentially BAD thing to be worrying about- Heartbleed partially stemmed from this thinking and with correct, modern systems, you really don't have any business dealing with much of what Autotools corrects for. GNU probably needs to do a cruft removal of the codebase, in light of what happened with Heartbleed) You can use it to do your project and it might work nicely for a smallish project that you don't expect to work anywhere except Linux or where the GNU toolchain is clearly working correctly on. The statement that it "integrates nicely with Linux" is quite the bold statement and quite incorrect. It integrates with the GNU toolsuite reasonably well and solves problems that IT has with it's goals.

This is not to say that there's no problems with the other options discussed in the thread here.

SCons is more of a replacement for Make/GMake/etc. and looks pretty nice, all things considered However...

• It is still really more of a POSIX only tool. You could probably more easily get MinGW to build Windows stuff with this than with Autotools, but it's still really more geared to doing POSIX stuff and you'd need to install Python and SCons to use it.
• It has issues doing cross-compilation unless you're using something like Scratchbox2.
• Admittedly slower and less stable than CMake from their own comparison. They come up with half-hearted (the POSIX side needs make/gmake to build...) negatives for CMake compared to SCons. (As an aside, if you're needing THAT much extensibility over other solutions, you should be asking yourself whether your project's too complicated...)

The examples given for CMake in this thread are a bit bogus.

However...

• You will need to learn a new language.
• There's counter-intuitive things if you're used to Make, SCons, or Autotools.
• You'll need to install CMake on the system you're building for.
• You'll need a solid C++ compiler if you don't have pre-built binaries for it.

In truth, your goals should dictate what you choose here.

• Do you need to deal with a LOT of broken toolchains to produce a valid working binary? If yes, you may want to consider Autotools, being aware of the drawbacks I mentioned above. CMake can cope with a lot of this, but it worries less with it than Autotools does. SCons can be extended to worry about it, but it's not an out-of-box answer there.
• Do you have a need to worry about Windows targets? If so, Autotools should be quite literally out of the running. If so, SCons may/may not be a good choice. If so, CMake's a solid choice.
• Do you have a need to worry about cross-compilation (Universal apps/libraries, things like Google Protobufs, Apache Thrift, etc. SHOULD care about this...)? If so, Autotools might work for you so long as you don't need to worry about Windows, but you're going to spend lots of time maintaining your configuration system as things change on you. SCons is almost a no-go right at the moment unless you're using Scratchbox2- it really doesn't have a handle on cross-compilation and you're going to need to use that extensibility and maintain it much in the same manner as you will with Automake. If so, you may want to consider CMake since it supports cross-compilation without as many of the worries about leaking out of the sandbox and will work with/without something like Scratchbox2 and integrates nicely with things like OpenEmbedded.

There is a reason many, many projects are ditching qmake, Autotools, etc. and moving over to CMake. So far, I can cleanly expect a CMake based project to either drop into a cross-compile situation or onto a VisualStudio setup or only need a small amount of clean up because the project didn't account for Windows-only or OSX-only parts to the codebase. I can't really expect that out of an SCons based project- and I fully expect 1/3rd or more Autotools projects to have gotten SOMETHING wrong that precludes it building right on any context except the host building one or a Scratchbox2 one.

Crass

The section mentioning Heartbleed detracts from this frustrated rant. The problem there was OpenSSL NOT using a configurator type package to detect broken malloc's but re-implementing system libraries and defeating platform developers who produced libraries which would have detected flaws much sooner. One reason to port programs is they become higher quality as they are less dependant on those little assumptions you don't evcen realise you're making – Caustic

The thing is that it doesn't detract from it at all. With Autotools, you're worrying about compensating FOR things like that- those re-implementations is an EXPANSION of that very thinking. Taking it to the next level as it were. You should view that from that backdrop...at which point it doesn't detract from it at all. You didn't finger the root cause in your reasoning- just what happened. I'm fingering the exact THINKING that brought it to that along with Shellshock and a few others like it. If it's broken, you should FIX it. If you can't- you should ask why keep it going. – Crass

I don't doubt that autotools and scons suck, but this answer does a poor job at noting the cons of CMake (my preferred build system, only because of the very, very sad state of build systems). Basically, CMake is a fractal of inconsistency with built-in support for individual edge cases rather than some core abstraction that handles most things. It's definitely the duct tape and bailing wire of programming. I'm sure I'm doing something wrong, but it doesn't support VisualStudio unless you find one VS project per CMakeLists.txt acceptable (I'm not a VS user, but my Winfriends tell me it's bad). – Enterprise

Unlike other hated programming tools, there isn't sufficient material to make a book called, "CMake, the good parts" (maybe a pamphlet or a blog post), and it's more of a fractal of bad design than PHP. – Enterprise

Wow, talk about unopinionated answers at SO! – Blackfellow

At least I back my opinions up with detailed facts, rustyx... >:-D – Crass

@Enterprise What's the issue with that? Visual Studio's usage of "project" is a misnomer, in my opinion; solutions should be called projects, projects should be called modules. (Especially as you almost always get a solution generated even when creating only a single project.) – Trinee

@Trinee I'm told by VS users that this is not idiomatic. In fact, CMake was replaced as the build system for our project because no one could figure out how to produce said "idiomatic" VS Project files. – Enterprise

weberc2 : I didn't say there wasn't issues. Having said this...what you talk to in your comments? The moment you used "fractal of inconsistency" (seriously?) as a term of use, you made it clear that nobody could even remotely take you seriously on this subject, sadly. Now, if you've got solid, valid examples that are NOT something where you're trying to wedge MICROSOFT'S notions of how things are supposed to be onto everything else (Tip of the hat to JAB, there...) which are very much drinking the kool-aid...and are actual problems...we can talk. – Crass

For the record I build software from source as a user all the time, and as such a user properly set up autotools projects are in fact far more pleasant for me. I mean, once I've built CMake and whatever else from source, running them is actually rather pleasant and painless, but originally or upon needing a newer version having that as a build dependency was painful enough that seeing anything other than a ./configure && make in the build instructions used to send a visceral anger-spike through me. Much less intensely nowadays, but it's still there. – Poky

YOUR take. Not a relevant item within the context and doesn't talk to the ISSUES I talk to. – Crass

The moment you find it easy for Cross-compile (which it doesn't seem you're doing...user...I'm making distributions and the like...) we can talk. Otherwise...sorry... – Crass

Note, that nowadays there's also Meson build system, and a lot of projects has moved from autotools to Meson. In particular that did such core projects as Mesa, xserver, libinput. AFAIK cross-platform works with it quite nicely, and it has pleasant syntax. – Nimitz

It's an (major) improvement, but I assure you that it's not a silver bullet, based on my WIP attempt at reviving EFL's metadata layer for meta-openembedded inclusion. It's cross-compile functionality handles things like GCC correctly, but if you need generators for content (EFL can...) you need to account for specifying the alternates. EFL doesn't account for it, nor does E for the Meson build setups for each project, so I'm stuck using the OLD Autotools which is one of the few not utterly broken in odd ways. – Crass

Godot Engine has been using Scons for Cross-platform build system for a while now. So cross-platform con on scons doesn't make much practical sense now. – Muffler

Might want to note the DATE on this. Scons has other issues, but it's moved up to first class citizen status in regards to this along with CMake and Meson. Ultimately? Your needs will be dictated by the tools- and, well, Autotools still stinks on ice. X-D – Crass

Answer 2

An important distinction must be made between who uses the tools. Cmake is a tool that must be used by the user when building the software. The autotools are used to generate a distribution tarball that can be used to build the software using only the standard tools available on any SuS compliant system. In other words, if you are installing software from a tarball that was built using the autotools, you are not using the autotools. On the other hand, if you are installing software that uses Cmake, then you are using Cmake and must have it installed to build the software.

The great majority of users do not need to have the autotools installed on their box. Historically, much confusion has been caused because many developers distribute malformed tarballs that force the user to run autoconf to regenerate the configure script, and this is a packaging error. More confusion has been caused by the fact that most major linux distributions install multiple versions of the autotools, when they should not be installing any of them by default. Even more confusion is caused by developers attempting to use a version control system (eg cvs, git, svn) to distribute their software rather than building tarballs.

Belated

True, though you make it sound like it's bad to use a VCS to distribute software. If the contents of a checkout or clone are the same as the contents of a tarball, why would you recommend tarballs? – Linseylinseywoolsey

@Toor I do not understand your question. All of the projects I work on produce a tarball which is distinct from the VCS checkout. Keeping the two distinct helps with reliable distribution. – Belated

yes, for sure. It just seems like a stupid idea to commit compiled files to the repo. I'm not sure why you were bringing that up unless perhaps you worked on a project that did that and have a gag reflex now. ;) "If the contents of a checkout or clone are the same as the contents of a tarball" was part of my question. I see lots of projects asking you to use git or svn to get the latest version. None of them have had compiled files in their repos. I think things like hooks or git-filter-branch might take care of cleaning things up a bit for the "release" branch. – Linseylinseywoolsey

It is true that a lot of projects ask people to use the VCS to get the latest release, but that is only appropriate for developers. Unfortunately, many users fail to understand the distinction between the release tarball and the VCS. Attempting to build from the VCS imposes more dependencies. The user may need asciidoc or help2man or doxygen or, importantly, the correct autotool combination. This has been a huge marketing problem for the autotools. Users wrongly think they need autoconf installed because they do not understand the difference between the tarball and the VCS. – Belated

Why can't a project distribute Cmake's output, project files and Makefiles for common platforms eg) Win, Linux and MacOSX? It seems like same situation as with lex/yacc tools, you include the genarated C code so it can be built on platforms without the tools – Caustic

Autotools projects (those that are properly built) do ship everything so that the package can be built without using any non-standard tools. The biggest draw back to CMake is that the packages rely on the user having CMake installed. – Belated

@William: what you mean by "the packages" is not clear, see I find docs that explain Cmake generates a makefile or project file for VS, which you then use in normal way. For a binary based platform from one vendor like Win, why would this need to be regenerated more than once per release by the release team? It seems like a deliverable – Caustic

There is no need to include Makefiles at all in a binary package distribution because the executables are being distributed. When a user downloads a source distribution that uses CMake, they are downloading a package that can be used on any platform on which CMake is installed, and including Makefiles that will work on all platforms is problematic. – Belated

While I think the points mentioned in this discussion are correct, I do believe that this discussion is missing the point. The user needs to install whole bunch of other things and whether or not he additional needs to install cmake should not be a big issue. I would worry more about libraries, the compiler tool chain, and other tools which are needed to build the software. – Neslund

A bit late to join the discussion, but kudos for you to state clearly that The biggest draw back to CMake is that the packages rely on the user having CMake installed. Sounds like a deal breaker to me. I switched recently from autotools to CMake for various reasons, and have since tried to find a way to create a package containing the sources, target-specific Makefiles, and optionally pre-built binaries. And there's just no way to do that with CMake. – Santonin

The problem begins with you dismissing the need of Autotools in the packaged condition and insisting that CMake is needed. If you're shipping a tarball/package of the project as-built, then you don't need to have CMake either. If you're saying that you don't need Autotools when the project uses it to frame things in and you can hand a configure.sh type thing to people, you're GRAVELY mistaken. In that context, I can assure you that it'll be needing you to do aclocal, etc. on the target machine. SO...in short, you got -1'ed on this score because it's not QUITE as you describe. – Crass

As for "needing to have CMake installed" as an argument, let's go over this one more time. 1) Normal end-users will NOT be using any of this. 2) In order for an autotools based build to do the "right" things other than on a narrow range of "<X>" where <X> is Linux, OSX, etc. you can ship just a tarball and build without needing Autotools. For most conditions where you're shipping a source tarball, etc. you're going to find that it DOESN'T WORK RIGHT (e.g. Cross-compilation...) and we're back to needing it installed. – Crass

This "needs to be installed" saw is old and rusty and applies to EACH AND EVERY BUILD SYSTEM TOOL- you get it installed by default on many Linux distributions because it's GNU and ONLY because of that. Having CMake installed on those systems, by the by, is merely an action, just like you'd have with Autotools if it wasn't installed by default to be installed by the package manager. On Ubuntu, by the by, Autotools won't be installed any more likely than SCons or CMake. – Crass

Saying "it needs to be installed" is really pretty much DONE and it's not a basis for saying "no" for a given tool because of that. Picking things because it's "going to be on the machine" is rubbish- because even Autotools ISN'T. Can we QUIT flogging this deceased equine already? – Crass

@Svartalf, I whole-heartedly agree that end-users should not need CMake, but should be using a package management system. The same holds for autotool generated packages. If you find yourself needing to run aclocal, etc. to install an autotool generated package, then I would suggest you are taking the wrong approach. When you find a tarball that is broken like that, you should report it as a bug to the maintainer rather than try to hack a solution. – Belated

The problem begins with a presumption that the code is buildable on a Linux platform, on the version of autotools you're using, etc. Under Windows, you can't build the way you're talking to. Technically, you'll have issues with OSX trying to just "configure" it. Sorry, you're defending a poor position the moment you agreed with "package" system. If you're building from source, you're a developer or a power user, and the BUILD SYSTEM is the user for that- and simply put, Autotools doesn't do well with anything other than the FSF's problem set. – Crass

If you aren't needing to fix problems with SERIOUSLY broken cowpilers (The FSF does...in order to provide at least a bootstrap of a relatively sane compiler...) then Autotools is grotesque overkill and trying to do neurosurgery with a sledge as a tool to make build systems sane and maintainable. It's like my rant indicates...I can assure you 1/4 or more of the build setups with Autotools will NOT cross-compile or handle Windows gracefully and correctly. The converse about CMake? Not so much so. It's TOO easy to make dumb, dumb mistakes with Autotools. – Crass

Huh? I agree that the autotools are not a packaging system, yet you continue to treat them as if they are. The problem with CMake is that it is not suitable for "power users" because it is insufficiently flexible. And if you're not a "power user" then you should be using a packaging system. So you seem to have made my point for me. I suspect your 1/4 number is way too low; I would estimate that at least 60% of the projects that use the autotools are horribly broken, and use the tools incorrectly. But the autotools have the potential to be used correctly, while CMake lacks power. – Belated

But please note that this answer was given over 3.5 years ago, and I have not followed CMake at all since then. Perhaps CMake now has more power than it did then, and can actually be used in a reasonable manner. – Belated

But even "power-users" should be using a packaging tool. Unless you are working as a developer on the build system for a piece of software, you should never be running the autotools. Most developers on a project are not working on the build system, and should not be running the autotools. End users absolutely never should. If you want to build from source, you build from the tarball, not the VCS. – Belated

A related answer arising from a misunderstanding of what Autotools are for and how/when to use them. – Hockett

So we should check in only configure.ac and Makefile.am into source, and let make dist to generate the tarball? – Warehouse

Just want to emphasize that I build software from source as a user all the time, and for people like me the difference between "I don't have to install anything besides the compiler and the libraries I'll be using" and "I have to install (or worse, build from source) yet another building tool" is non-negligible. – Poky

To use the CMake example: CMake isn't too bad to acquire normally, until you're on a minimal or old system and you just want to quickly build a C project but it needs CMake so you need to build that but that needs a C++11 compiler so you need to build that. And now what would've been a few minutes of waiting for ./configure && make turns into a day of bootstrapping a sufficiently recent C++ toolchain for the target system. – Poky

@mtraceur: Hint for you... If it's non-negligible, you're going to have a problem for ALL of them. If you get to brass tacks, NONE of the build engines, not even gmake is going to be installed for you. It's a non-starter and as an observation, the comment that you're compiling from code means I won't be shedding a single tear for YOU. You're on your own just as I am and everyone else is. – Crass

As for building on an OLD system? To be blunt, DON'T. Most of the, "old," systems you hint at can't compile modern code in the FIRST place. People need to quit putting up straw men to knock down. YOU, especially. – Crass

@WilliamPursell : It should be noted that your brushing off the remarks doesn't get you anywhere. What if you're the gent doing that packaging system (Waves hand) and for much, much more than an X86 class machine at the same time (Waves hand). This crap is BUSTED in many cases, and entirely too easily so. You don't want "power" which is a MORONIC (Yes, I did say that) thing to say about this. You want it to build code. Period. You want it to do it for cross-compile as well so it can be built on an X86 for an ARM, MIPS, etc. – Crass

You want to do this because it and a Power (Which would be another case of "faster" for right now at least) are the only decently fast machine classes that anyone can grab up and build for an embedded or other target. All of the comments people have on this are all pretty much presuming you're building ON the target. Which couldn't be further removed from the case. – Crass

Until someone fields an ARM, MIPS, or RISC-V, you're not going to realistically build code ON the target environment for over HALF the cases where most code might see being built. The moment you presume you're just building on YOUR machine or on a Target system and ONLY one, you LOSE. – Crass

@Crass Huh? What remarks am I brushing off? At the time this discussion began (nearly 7 years ago) CMake was an utterly immature build system. The autotools were (are) a highly abuse, misunderstood, and arcane system which many people try to shoehorn into a full fledge packaging system. I do want power, and flexibility. And that is why I prefer the autotools over CMake (although I don't really do any packaging work any more.) – Belated

Are you claiming that CMake is better for cross-compiling? That's a remark I've never heard before. – Belated

If you want power, you should look at SCons or Meson. Not Autotools. It's a flat-out mess that you own are an arcane thing that is highly abusable. The power you seek is in the other two and is vastly less arcane and actually do the things I talk to. Autotools doesn't. – Crass

Yes, it, SCons and Meson are actually MUCH better at cross-compilation than Autotools and are less likely to violate all sorts of rules. – Crass

And, if you've never heard it before, I would question how much you've honestly heard. – Crass

Great. But how is that relevant? I have not doubt that build tools are better now than they were 7 years ago. That has absolutely zero relevance to my answer, which is merely pointing out that (7 years ago), using the autoconf generated configure script to build software is not using the autotools, while using CMake to build a package is using CMake. – Belated

Regarding you latest snide comment; this conversation is a time machine. It is from 7 years ago. And I don't pay attention to build tools any more because I don't do any packaging work any more. If CMake works for you to cross compile, that's great. Use it. And be aware that you are using it. Not sure what your complaint is, but you might want to consider anger management therapy. – Belated

Answer 3

It's not about GNU coding standards.

The current benefits of autotools — specifically when used with automake — is that they integrate very well with building Linux distribution.

With cmake for example, it's always "was it -DCMAKE_CFLAGS or -DCMAKE_C_FLAGS that I need?" No, it's neither, it's "-DCMAKE_C_FLAGS_RELEASE". Or -DCMAKE_C_FLAGS_DEBUG. It's confusing - in autoconf, it's just ./configure CFLAGS="-O0 -ggdb3" and you have it.

In integration with build infrastructures, scons has the problem that you cannot use make %{?_smp_mflags}, _smp_mflags in this case being an RPM macro that roughly expands to (admin may set it) system power. People put things like -jNCPUS here through their environment. With scons that's not working, so the packages using scons may only get serialed built in distros.

Sisto

+1, and the world would be a better place if this were true. Sadly, ./configure CFLAGS=-O0 fails often with packages that overwrite CFLAGS in the makefile and require instead that the user run ./configure --enable-debug. (eg tmux). – Belated

It's no more confusing than Autotools and as William rightly points out, it gets busted all to hell with an improperly framed CFLAGS = "<foo>" in the makefile. Quite simply this is another one of those "old saw" items. And the CMake examples are bogus...again... You can do the first if you're not specifying RELEASE or DEBUG. FAIL. – Crass

Answer 4

What is important to know about the Autotools is that they are not a general build system - they implement the GNU coding standards and nothing else. If you want to make a package that follows all the GNU standards, then Autotools are an excellent tool for the job. If you don't, then you should use Scons or CMake. (For example, see this question.) This common misunderstanding is where most of the frustration with Autotools comes from.

Heine

GNU standards can be disabled in Automake with AUTOMAKE_OPTIONS = -foreign in your Makefile.am. (Or -foreign in your autogen.sh. I think almost everyone uses this.) – Myself

Yes, but that only controls whether Automake enforces superficial GNU rules like whether a README file is required. It doesn't change the basic premise of building a GNU-style tarball with rules like installcheck and distclean. If you try to change that sort of behavior while still using Autotools, then you're just wasting your time. – Heine

They (in theory) allow all software packages to be built and installed in exactly the same way. – Heine

They, in theory, allow you to deal with BROKEN compilers and OSes more appropriately than with other tools and to apply superficial rules like @Heine highlighted there. If you're using a modern (say GCC or clang...for examples) tool on a modern operating system with nothing really goofy, say Linux or current *BSD, you don't NEED the "rules" there. They, actually, make much, much more work for you and can't help, honestly for cross-compilation. Nearly half of all usages these days are for embedded Linux and *BSD. WHY are you going with things that can't help you there? – Crass

Not sure why you downvoted the answer, since you seem to acknowledge it in your comment...? – Heine

Answer 5

While from a developers point of view, cmake is currently the most easy to use, from a user perspective autotools have one big advantage

autotools generate a single file configure script and all files to generate it are shipped with the distribution. it is easy to understand and fix with help of grep/sed/awk/vi. Compare this to Cmake where a lot of files are found in /usr/share/cmak*/Modules, which can't be fixed by the user unless he has admin access.

So, if something does not quite work, it can usually easily be "fixed" by using Standard Unix tools (grep/sed/awk/vi etc.) in a sledgehammer way without having to understand the buildsystem.

Have you ever digged through your cmake build directory to find out what is wrong? Compared to the simple shellscript which can be read from top to bottom, following the generated Cmake files to find out what is going on is quite difficult. ALso, with CMake, adapting the FindFoo.cmake files requires not only knowledge of the CMake language, but also might require superuser privileges.

Shatterproof

I don't think problems with Autotools are "easily fixed" in comparison with CMake... – Timberlake

why do you think so? – Shatterproof

Because autotools is a complex system (just like CMake). If you think Autotools are "easily fixed" (there may be reaons to think this), it would be good IMHO to explain in the answer in what way problems are easier to fix. – Timberlake

autotools generate a single file configure script and all files to generate it are shipped with the distribution. it is easy to understand and fix with help of grep/sed/awk/vi. Compare this to Cmake where a lot of files are found in /usr/share/cmak*/Modules, which can't be fixed by the user unless he has admin access. Have you ever digged through your cmake build directory to find out what is wrong? Compared to the simple shellscript which can be read from top to bottom, following the generated Cmake files to find out what is going on is quite difficult – Shatterproof

Yes, that makes sens, thanks. I took the liberty of adding it to your answer. Feel free to revert :-). – Timberlake

... it can usually easily be "fixed" by using Standard Unix tools (grep/sed/awk/vi etc.) ..., well I had encountered a problems, where ./configure or autogen.sh didn't work at all. These problems led to no build at all, compared to CMake build with errors... – Jolt

well, without code it is difficult to say if it was really unfixable. – Shatterproof

You can always use your own local version of cmake; there's no reason to use what's installed at the system level. For anyone doing cross-platform work, that's completely normal; it's certainly the way I use cmake most of the time. – Freetown

@JamesMoore and then you just have to copy all the Modules installed by thirdparty libraries into your local copy..... – Shatterproof

@Shatterproof You're almost certainly doing something like that anyway. Repeatable builds can't rely on libraries being installed on the system you happen to be building on, so you're just replacing a set of steps (perhaps apt-gets, whatever your system uses) with a different set of steps that get your dependencies into a known place in your local tree. – Freetown

Simple shellscript? X-D What drugs are YOU on? Here's a snippet of what Autotools does for you: exitcode=0 as_fn_success || { exitcode=1; echo as_fn_success failed.; } as_fn_failure && { exitcode=1; echo as_fn_failure succeeded.; } as_fn_ret_success || { exitcode=1; echo as_fn_ret_success failed.; } as_fn_ret_failure && { exitcode=1; echo as_fn_ret_failure succeeded.; } if ( set x; as_fn_ret_success y && test x = \"\$1\" ); then : else exitcode=1; echo positional parameters were not saved. fi test x\$exitcode = x0 || exit 1 test -x / || exit 1" – Crass

And there's CRAPLOADS of this. Let's be honest with each other here, folks, you're more comfy with Autotools (WHY, I'm unsure...as it's insane...) In the end, you're going to use whatever you like. But I can assure you that 100% of the time that your, "simple shell scripts," won't get all cross compilation right because your testing has to account for that out of box. And Autotools WON'T do this for you. There's a crapload more work involved, more than with Meson, MUCH more than with SCons or CMake for handling one of the MAIN contexts for this stuff there. – Crass

DO NOT EVER use autotools in your new projects. – Ledeen

@Crass sed -e "s,exitcode=1,exitcode=0,g;s,extit 1,exit 0,g" configure would be a first shot at beating this script into submission. – Shatterproof

@Shatterproof you really like autotools. – Piccalilli

1) Realize that unless you're a developer, the end-user ISN'T the end consumer of your codebase. It rather doesn't matter from a USER'S point of view what you use. 2) The person that's using your tool is the one generally is going to be providing a USER what gets used. This should be a solid hint. Get in my way of making an easy release of your stuff- you'll be ignored if possible and reviled if not. Remember...developers aren't your users. This is a DEVELOPER distinction. Apply a blunt object over the back of your head until you disabuse yourself of the notion. – Crass

At this point, so far, CMake, Meson, and SCons are the current triumvirate for producing binaries in a clean, cross-compilable manner. Unless you have enough muscle to build ON TARGET (Read: X86, POWER right now...maybe eventually ARM and RISC-V) you're going to be cross-compiling. Get in someone's way and you're going get cussed, etc. The parts of the rant from 12 (seriously, people...) years ago regarding Autotools still stands. If you're going to INSIST on using that POS, make sure you have cross-compile working right or you're just adding to the validity there.. X-D – Crass

@Shatterproof Ah, let's do global search and replaces. The last time of that sort of first-shot, it made a worse mess of things. Worse, I rather SHOULDN'T have to do that if you pause to think. You're making the same mistake that everyone else that I gritched about does. That you're doing your users a favor. Nope. Pretty much the devs that are downstream of you a disservice. It only really works for people when you're not the one packaging and you're building raw. Ever seen someone do that in modern times? – Crass