hard , @bonifartius, autotools is horrendously slow
@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.
@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 @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.
@bonifartius, I always patch those downloads to local lib first thing, but I imagine it can be painful if the dependency chain does that.