@cnx maybe for developing. for actual deployment it's hellish. every project invents it's own bad way to download dependencies and other stupid things. autotools based projects usually just work with dependencies installed from packages.

the solution of the cmake projects then isn't to fix the build system, but to publish docker containers or flatpaks or something equally shit.

every project invents it’s own bad way to download dependencies and other stupid things

That’s in no way CMake’s fault, @bonifartius, I’ve seen people putting that abomination in Makefile and even straight up invent their own build.sh. The reason you see more people doing that shit with CMake than Autotools is that CMake is simply more popular with the younger crowd that are likely recently migrated from dystopian hellholes like Windows or macOS and don’t care to integrate to the local culture.

@cnx i think my problem with cmake is that it's so opaque to me.

if there is a make rule downloading stuff, i can understand what is happening and where things are going to. same for most "build.sh" like things.

with cmake there are dozens of variants of "downloading stuff from github™️", but i regularly fail to find out where things are saved/extracted to, what is downloaded, etc. all is hidden in complex cascades of rules n stuff. not fun.

cmake might be fine in principle but it does seem to invite people to do these things.

@bonifartius, I always patch those downloads to local lib first thing, but I imagine it can be painful if the dependency chain does that.

@bonifartius @cnx It's actually fairly straightforward if they are using FetchContent, there's a directory in the build directory (usually _deps) that holds all of them. If not I feel your pain.

Most of the problem with cmake after the syntax (which I agree is horrid) is the fact that it's a old project with a lot of things you can use, but probably shouldn't because they've added better things. And anything explaining the best things to use is a book you have to pay for.