Please substantiate the claim about how "cmake fights that at every possible step." There's so much hyperbole in your statement that it really does seem like you've spent "years of experience with cmake" futzing around.
So, assume that you need byte-for-byte identical upstream dependencies, and also assume you want to run in a modern CI environment. In make, you build a docker with a line like:
RUN tar -C opt xvf /…/foo-1.2.3.tgz
RUN <build the thing if needed>
And a few lines like this in make:
INC += $(wildcard /opt/foo-*)/include
LIBS += -L…
This generalizes elegantly to subdirectories. (See “Recursive Make Considered Harmful” for the right way to do it), and (crucially!) it won’t build if you don’t have the build environment set up correctly.
It also lets you prevent the CI build container from talking to the internet, so outages of upstream server infrastructure, or package-manager-du-jour serving bitcoin miners can’t directly break production binaries.
It also generalizes to building in other people’s operating systems, etc.
With cmake, you need to read the documentation for find_foo, which invariably has a different calling convention than find_bar (if it exists at all), and it will try to look places it should not for the library. Adding a library this way takes hours.
Also, the docker + make approach works well with languages other than c/c++; cmake does not, unless cmake happens to include built-in support for the language in question.
You can just add_library a filepath in cmake too. You don't have to use the find module. It isn't idiomatic cmake, but it's 100% possible. It sounds like you have specific niche needs, so it's a reasonable approach for your case. IMO it's unfair to criticise cmake for this, since it can do the exact same thing as make in this instance.
I don't know what exactly the poster was dealing with, but I've been trying to get reproducible builds out of cmake and it was a serious pain due to cmake insisting on using absolute file paths.
I can't tell you whether this is/was innate cmake behavior or whether something was wrong with the specific project, but cmake passed all source file names to the compiler using the full file system path rather than a relative path.
This is a serious (though slowly becoming a non-issue) problem since compilers encode source file names into the output binary's debug information and strings (__FILE__). The "-fdebug-prefix-map=old=new" GCC option and its cousins are what is slowly making this a non-issue, but those are a relatively recent addition.
RUN tar -C opt xvf /…/foo-1.2.3.tgz RUN <build the thing if needed>
And a few lines like this in make:
INC += $(wildcard /opt/foo-*)/include LIBS += -L…
This generalizes elegantly to subdirectories. (See “Recursive Make Considered Harmful” for the right way to do it), and (crucially!) it won’t build if you don’t have the build environment set up correctly.
It also lets you prevent the CI build container from talking to the internet, so outages of upstream server infrastructure, or package-manager-du-jour serving bitcoin miners can’t directly break production binaries.
It also generalizes to building in other people’s operating systems, etc.
With cmake, you need to read the documentation for find_foo, which invariably has a different calling convention than find_bar (if it exists at all), and it will try to look places it should not for the library. Adding a library this way takes hours.
Also, the docker + make approach works well with languages other than c/c++; cmake does not, unless cmake happens to include built-in support for the language in question.