is cmake worth studying / using?

[ggodw000]

I touchbased with cmake utility. Appears to make make utility simpler. There are several projects at work use extensive the cmake so here we go.
It appears it makes a tons of files in the current and one build directory, just building a simple 1-2 files + few library.
Seems overkill.
May be benefit comes from scaling when you start to manage multiple compile files and libraries?

[Thomas]

Hi ggodw000,
cmake is really popular and it would be good to learn about it. If your existing system at work is not using cmake, I wouldn't bother. I usually mess with build stuff only to fix something that is broken or to improve efficiency!. This is just my point of view.
--Thomas

[moonchild]

Cmake is a mess. Not worth learning it any more than you have to for work. Its one virtue is that it's better than autotools. It does scale somewhat better than straight make, but make can be made to scale (see linux).

There aren't any good build systems, but insofar as there are interesting build systems, cmake doesn't bring anything of value to the table. Meson is like a better version of cmake; djb redo is flexible and simple; tup is supposed to provide certain correctness guarantees (though really it's a mess); bazel likely scales better.

Ultimately, if you are looking for a novel build system (and don't want to build your own), I recommend looking at redo. But plain make (esp. gnu make) is still serviceable enough.

[nullplan]

Its one virtue is that it's better than autotools.

Setting the bar high, are we? I have heard about as many good things about autotools as I have heard about SAP, that is to say none. I don't know why anyone uses either.

But plain make (esp. gnu make) is still serviceable enough.

GNU make tries to combine POSIX sh with POSIX make. So here's an idea: Just use a shell script that creates a Makefile.
Anyway, I dislike cmake for all nontrivial things. When you are just compiling a bunch of C/C++ files into libraries and executables, it is awesome: You just list the source files and cmake does everything else. But in a kernel, you might need to do other things. You might need to compile tools with the host compiler and run them to generate some files. You might need to compile a shared object that is then included in an object file (that's how Linux does the VDSO), and you might need to link that particular shared object with a special linker script.

Whenever you need weird things, cmake is not the tool of choice. I hand-roll a Makefile, but am thinking about rolling a Makefile generator.

[ggodw000]

it says it could make the cross compiler easier with cmake. It seems it can generate appropriate build files for gnu, visual studio (win) and xcode (apple?) but you have take care of libraries and paths too with each cross compilation.

[nexos]

In my opinion, make is the best. I have tried CMake, but it is quite bloated. make is lightweight (surprising for GNU), and easy to learn. If you really want to be modern, meson seems good. I personally haven't tried it, but it seems to be good however.

[Solar]

It completely depends on what you are doing.

For a small app of a couple of source files that you wrote for your own use, a quick Makefile is completely sufficient.

When the app grows, you can scale up to a "real" Makefile that does proper header dependencies, cleanup etc.

But how many Makefiles have you seen that do even that much, properly? And the scaling-up pretty much ends there, unless you're a real wizard with make... and which version of it, anyway?

If your app grows and gets popular, you are going to face issues. You will want to test your app against various versions of third-party libs. You might want to be cross-platform, or at the very least cater for people with different tastes in development environment. (Eclipse CDT vs. ninja vs. make vs. ...) You might want to make use of advanced CMake features, like automated testing, continuous integration, build / test dashboard, or packaging. You might want to integrate other tools into your build process, like code formatters, doxygen, valgrind, or LaTeX for building documentation.

Make and CMake are for different things. Make is one step up from a build script, with an eye on dependency handling, Autotools were a step up from Make trying to do some of the things I mentioned above and making a fine hash out of it. CMake is one or two steps up from autotools.

Point in case, you might want to have a look at my JAWS CMake template setup. I used it for several years to build two seriously large C++ applications at work, and its use has spread into other projects / teams. It is no longer actively maintained, and uses some techniques that are considered obsolete now, but it is / was perfectly servicable. It created DEB packages for Debian-based systems, RPM for RedHat-based systems, and a setup.exe installer for Windows systems, on demand, on checkin, and nightly. It serviced Make builds (both native Linux and MXE-supported MinGW cross-builds), Ninja builds, NMake builds, and MSVC solutions. Every morning I looked at the CDash dashboard to check if all the builds went well, and if they didn't, I could look up the logfiles to check what went wrong, and with which build / commit.

This goes well beyond what make can do. Overkill for a small app? Yes. Useful for a large, potentially cross-platform app? Hell yes.

It's even more of a no-brainer when you approach it from the other side (VisualStudio). I'd prefer a CMake setup over maintaining a .sln any time.

[nexos]

@Solar, that makes sense. But, here is what I think each build system is useful for
make - Simple apps, and (In my opinion) operating systems, because of the large amount of control it gives over building
autotools - apps that work on all POSIX platforms. Autotools is a big step above make, but is very bloated, unlike lightweight make.
cmake and meson - useful for cross platform apps. CMake seems to be bloated, so I would probably choose Meson. But that is just my opinion

[PeterX]

Can CMake automatically find include instructions in C files?

Greetings
Peter

[Solar]

Can CMake automatically find include instructions in C files?

No. (Neither can Make.) But the compiler can, and can provide that information for the build system. CMake can (and will) "do the magic" necessary for the target build generator.

(In case this wasn't clear, CMake is a "meta buildsystem", which will generate Makefiles or Ninja files or NMake files or MSVC solutions or ..., depending on what you're asking it to generate. You then use that to make / ninja / nmake / ... your binaries.)

[Solar]

cmake and meson - useful for cross platform apps. CMake seems to be bloated, so I would probably choose Meson. But that is just my opinion

There are more meta-buildsystems around, sure. When I opted for CMake, Mason did not even exist yet AFAIK, and your mentioning it here is the first time I've heard of it. Boost, for example, (easily one of the most important C++ projects out there) started moving toward CMake years ago, so...

As for bloat, I don't know... I dislike having my C++ build system rely on something else entirely (Python)...

[nullplan]

As for bloat, I don't know... I dislike having my C++ build system rely on something else entirely (Python)...

Erm... make is already a different language. Unless make is OK because it is written in C, but then Python should be OK for the same reason. I don't really get where you are coming from, here. I measure build system bloat mostly by the build time, and there, a portable makefile and "make -r" are usually unbeatable.

[Solar]

I'm coming from Make being written in C and CMake being written in C++, i.e., the languages they are / were primarily aimed to help with. Whereas Meson is written in Python, a language unrelated to what Meson is aimed to help with. Moreover, Python needs to be present at runtime, whereas Make / CMake don't have that kind of runtime requirement.

Meson's Quickstart Guide tells me how to install python3 python3-pip python3-setuptools python3-wheel, and shows me how to install Meson using Python's infrastructure (pip3). Why should I care, if I want to set up a C/C++ project? And if I run into problems there, I am stranded in unfamiliar territory...

As for build times, aside from the initial CMake config (which you don't have to repeat for subsequent iterative builds) those solely depend on the actual build system you told CMake to generate build files for. If you think make is fast, you should give ninja a try. I just ran a clean build of PDCLib with either system[*], and ninja slashed make's build time in half, plus it has the "better" output IMHO.

[*]: See what I did there?

I just like the options CMake gives me (and others who might work on my sources).

[nexos]

ninja requires Python as well. In my opinion, installing Python really isn't too bad, as when you install ninja or meson, it will automatically install Python. As for bloat, it doesn't really add bloat to your app. Maybe to the build system itself, but build systems are never going to be fully lightweight in my opinion. What I mean by CMake's bloat is the number of files it outputs in the build directory takes up disk space and has to slow it down. I don't have to much experience with Meson, but it appears to be lightweight (as it uses ninja by default). The motto for my OS has been to have as few lines of code in one file as possible, as the less code to run, the faster it gets and the less bugs that get introduced. Some sort of build system should follow the same philosophy. Hmm, maybe I just gave my self an idea for an app .

[nullplan]

The motto for my OS has been to have as few lines of code in one file as possible, as the less code to run, the faster it gets and the less bugs that get introduced.

The latter may be true, but the former is definitely false. Yes, code takes time to execute, but very often, more complicated algorithms can perform better in the long run. Think of sorting algorithms: Insertion sort can be written in three lines whereas smoothsort takes something like 100 lines. Yet smoothsort performs better on larger amounts of data. Still, I agree that less code is usually desirable.