Why? I don't see how it's different from requiring a user to install a compiler to build a particular language. Operating systems don't have every compiler installed by default. To fulfill your requirements, one would have to re-implement every build system and compiler in POSIX shell. Honestly the "better way" that I see a lot of projects going with is to just support multiple options for build systems, because there is no one perfect solution that is going to work on all platforms.
The elephant in the room here is windows, and at this current point in time, CMake is about as portable there as autotools because Visual Studio has built in support for it.
The various build systems I've seen, including CMake, are portability projects in themselves. Yes, to build a C++ program you need a C++ compiler. But if it's using CMake then you need CMake. Oh, but you don't have that. Ok, now you have to install that.
Oh, it requires Python X.Y (I'm not saying CMake does, but I've seen others that do, and CMake has other similar things)? Oh, this system doesn't have that. So now I need to build Python from source. Does Python have any dependencies, perhaps? (or worse, you have to use backports, which pull in 1000 dependencies so that now you have a frankensystem)
If you've ever been at the point where two steps down the dependency chain you have to build something as fundamental as Python, then you probably know that this is not a fun experience. And in fact you may run out of disk space, several gigs of source and object code later. (not every system is a 100TB server)
The whole thing about portability is that it should actually work even on systems the original developer does not have access to. If all you need to support is Ubuntu 18.04 (or newer) and Windows, then why not just have a Makefile and a MSVC project file? That would be much easier than CMake or autotools.
Oh, and I've also been hit by dependencies of the build system being too NEW. E.g. CMakeList.txt using features removed in newer versions.
And that's how autotools is different. The ONLY dependency is a POSIX shell. Do you have that? Then you can build.
The number of times I've seen CMake try to link with "-llibfoo" (it's "-lfoo") or be entirely confused about how I'm not running the exact same system the developer is, I can't even count. (e.g. failing to build because "this is not an amd64 system"… uh, yes it is, with zero logs about why it thinks that)
> The elephant in the room here is windows, and at this current point in time, CMake is about as portable there as autotools because Visual Studio has built in support for it.
Well that just means CMake has nothing at all going for it, if they are as portable.
you don't, CMake is able to bootstrap from nothing, it only requires a C++ compiler
> The whole thing about portability is that it should actually work even on systems you do not have access to. If all you need to support is Ubuntu 18.04 (or newer) and Windows, then why not just have a Makefile and a MSVC project file? That would be much easier than CMake or autotools.
having been in that exact place it's definitely not true
>Well that just means CMake has nothing at all going for it, if they are as portable.
Sorry, just to be clear, Visual Studio does not have built in support for autotools. (Unless they added it recently and I wasn't aware) But, there are a number of other less convenient ways to get that to work on Windows.
So then you need to either compile from src, or sideload install it and pray that cmake finds your new version instead of preferring the distro installed version.
Keep in mind that I have to do all this just to build some C++ binary because someone decided to not use autotools.
I've voted this post down for this in particular. It is truly an absurd criticism, especially when you refute it yourself when you admit bash on Windows is a relatively new phenomenon (and I still struggle with bash env on Windows). If you use a build system, you need a build system installed, full stop. Cmake is pretty easy to bootstrap on a new host with minimal assumptions. Literally just `./bootstrap; make` on basically any 'nix.
Cmake is designed to run truly anywhere, with many backing generators, not just make. It doesn't even assume a posix shell iirc.
Sounds like many of your complaints are with the library authors not writing with portability in mind.
I don't understand the argument, it seems very circular.
Most software packages have a number of build dependencies as prerequisites for building, including a compiler, build tool like make/ninja, libraries and headers, other processors and tools like doxygen, sphinx, static analysis etc.
What makes the "build system generator" so unique in its requirements that this one tool must be embedded in the source package?
Nothing.
It's a convention adopted by the GNU Autotools initially for pragmatic reasons--the requirement that the end user install m4, perl, and a few other tools, and that in the early days the breakage between autoconf and automake minor versions was routine and really annoying. Today you can just run "autoreconf -fvi" for the same effect, and many packages have stopped distributing the generated scripts. Many distributions regenerate them as a matter of course, making the distributed copies redundant. Today, when we have fully-described and automatic installation of build-dependencies on most platforms, the need for embedding no longer exists.
I'm afraid that I don't buy your argument. Don't mistake historical conventions established for a single tool with a hard requirement. The requirement doesn't actually exist.
I am saying that cmake is fundamentally broken and unfit for purpose even in addition to what you mention. I've mentioned some in another comment here, but really why cmake should be thrown in the garbage is too long a rant to fit into a comment field.
I am VERY interested in hearing new ideas. If you have a truly better way, then I want to use it.
Though I'm not sure why you say generating code is so bad. Code gets compiled to machine language, and (especially with optimizations and all the new fancy instructions) are not a thing that most people usually look at anymore.
Yes, actual developers need automake/autoconf installed. Of a sufficiently recent version. But what exactly is your suggestion? Autotools at least makes this an issue only for the developers (and not even all of them, since they may not need to change things), not for the orders of magnitude more users.
But this is not a unique thing to developers. There may be other generated code. E.g. they need to have protobuf compiler installed, with all the plugins required. End users, even those who build, don't. Developers who don't modify those parts don't.
But here's the main thing though: Any portable build system, that already requires EVERY user to have that build system installed, is DoA for being a viable portable build system.
It's incredibly frustrating to download a package, only to find that the build system the author in their infinite wisdom chose to use, has not been ported to your platform (or if it has, you have to yak shave for a few hours to get it and its dependencies installed). So you can't compile the thing.
The beauty of autotools is that it "compiles" to a "virtual machine" (shell) that will truly run anywhere. Nowadays even on Windows, which now ships bash.
CMake too fails on this aspect, in addition to all the other aspects this box won't be able to fit.
But please, I truly mean that if you have a better way, then I do want it. It's incredibly hard to build something portable though. Hence the minimal dependency of "just a POSIX shell" for autotools.