I think half those N's are cmake itself considering the amount of time I see "requires cmake x.x or above" messages.
I wouldn't find having many build system such an issue if they'd just add a makefile (and maybe ./configure) to call that build system, giving devs a consistent interface and not having to lookup up how to do a simple build.
> if they'd just add a makefile (and maybe ./configure)
That's the whole point of cmake. Instead of running autotool's ./configure (which in fact is a whole dance involving autoconf, autoreconf, automake, and whatnot) just run cmake . to get yourself a fancy makefile.
> just run cmake . to get yourself a fancy makefile.
Well most instructions I've seen start of with "mkdir build && cd build && cmake ../src", which is a bit more complicated than just "make" with a default build dir. I'm not sure why they're all like this, I would have though supplying a default build directory is something cmake could handle.
My last and only big project with cmake we ended up with a makefile anyway to drive all the things cmake couldn't do, or that we couldn't do with cmake due to inexperience or some combination of the two. So we ended up with make calling cmake calling make, all because it apparently made it easier for IDE users (it didn't but that was definetly our fault).
I use Make to automate the initial CMake setup step - though by "Make" I probably mean something more like "glorified shell script", as the Makefile in question consists entirely of phony targets. It detects the OS with the usual bunch of ifs, and by default does one of 3 things:
- Windows - generates a VC++ project
- OS X - generates an Xcode project
- Unix (other) - generates Ninja files for Debug/RelWithDebInfo
(Typically there's also the option to generate Ninja files on OS X if you like - good for automated build and/or if you'd just rather use some other editor (which is not unreasonable).)
Once it finishes, on Windows you load "build/vs2017/whatever.sln" into VC++; on OS X you load "build/xcode/whatever.xcodeproj" into Xcode; on Unix (other) you change to "build/Debug" or "build/Release" and run "ninja". And off you go. After that, it all just kind of runs itself.
The Makefile consists of basically stuff like this:
plus some ifs to ensure the right target(s) are available depending on host OS.
(I've found it beneficial to regenerate everything entirely from scratch each time in the Makefile - ensures you're always working from a clean slate, with no cached variables sticking around from old runs. The odd package does have an unusually time-consuming configuration process, but I've always ended up managing to bypass these somehow - it's possible a future revision of my "process" will have to actually address this properly.)
This process does confuse people that don't read the instructions, as they type "make", some stuff happens, and then nothing. But I've found it to work well enough.
> I'm not sure why they're all like this, I would have though supplying a default build directory is something cmake could handle.
cmake -H. -Bbuild && cmake --build .
Will do an out of source build with the default toolchain on windows/mac/linux. Has the added benefit of being parallel, and working with Visual Studio/Ninja/XCode.
Portable build files don't appear to be a design goal... if you want those, you probably need a different tool. They do exist.
As for distributing CMake, the intention is presumably that it's installed on the system of whoever's going to build the code, like make, or gcc, or whatever.
The dependences do not change upon distribution, so they can be safely encoded on the makefile. As for "detecting" the compiler, either it is in the path, or in the CC variable (or analogous), in which case the makefile can work; I do not honestly understand what is the task of cmake here. The only use that I can see is creating projects for other build-systems, e.g. for windows. But if you only distribute your code to posix systems, and your project is small(ish), then cmake does not really add anything.
The dependencies do change depending on the user. Different version of libraries will be in different locations, may require different build flags, etc, etc. Likewise the build may support a range of compilers which require (sometimes completely) different compiler options for a successful build. This is the reason autotools existed in the first place (and it was only intended to even out the differences between 'POSIX' systems in the first place).
In general though, if you're just talking about small projects, I have found the easiest way to incorporate smaller librares into a build system is to just ignore whatever build system they are using and re-write the build in the larger build system (even if they are the same tool!). This is mostly because the current state of build systems is so terrible.
> The dependencies do change depending on the user. Different version of libraries will be in different locations, may require different build flags, etc, etc. Likewise the build may support a range of compilers which require (sometimes completely) different compiler options for a successful build.
What you say is true, but it can be interpreted as either positive or negative features. I would say that code that depends on specific versions of a library or specific compiler options is bad code; and propagating bad code instead of fixing it is not a good idea. Cmake makes it very easy and convenient to ship bad code, as you explain. Thus, it is a force of evil! It allows, even encourages, the programmers to be sloppy without short-term visible consequences.
I'm talking about trying to make a shared library versus a static library vs an executable, or include different directories. I'm not talking about depending on '-O2' for correctness. Likewise with different versions of a library in different locations. And even in the case of more obscure flags, the cause is usually bad or incompatible compilers or libraries, not 'bad code' on the part of the project. A build system needs to be able to deal with a large variety of situations, because ultimately the responsibility for making the project build is on the project and the build system, not the user and their environment.
I wouldn't find having many build system such an issue if they'd just add a makefile (and maybe ./configure) to call that build system, giving devs a consistent interface and not having to lookup up how to do a simple build.