>Any portable build system, that already requires EVERY user to have that build system installed, is DoA for being a viable portable build system.
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.
> Why? I don't see how it's different from requiring a user to install a compiler to build a particular language.
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.
> But if it's using CMake then you need CMake. Oh, but you don't have that. Ok, now you have to install that.
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
I've built cpython, it's about as inconvenient as building the compiler and runtime for any other major language. What OS ships binaries for gcc/clang but not python? I can't say I've seen any Linux distros that don't have it.
>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.
Usually distros are one or two versions behind what many developers consider to be minimum viable version. For python especially, but also compilers if you want bleeding edge c++20 support.
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.
I've built it too. That's not the point. It's the yak shaving of "I just want to compile this thing here" that turns into "what options do I need for building Python", and "how do I then get these third party Python modules with a custom install script to install into the correct Python path. And what exactly should I set PYTHONPATH and LD_LIBRARY_PATH to".
Keep in mind that I have to do all this just to build some C++ binary because someone decided to not use autotools.
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.