19 ms·

From QMake to CMake: A story on why CMake is pretty nice in 2020

57 points by Kelteseth 6y ago

Rochus 6y ago
> Also, many people hate MOC. This is the pre compiler that compiles your Qt C++ into regular C++. MOC is not a pre-compiler but a code generator; all code written by the developer is compiled as is, but it can include macros known to MOC for which additional code files are generated. This goes without notice when e.g. using qmake or cmake. No reason to hate it.
formerly_proven 6y ago
The author points out the lack of emperor's clothes when he says that the choice of build system is primarily political and not based on technical merit, since politics elevate CMake above Qbs, even though the latter is a superior build system (syntax/UX x performance x correctness).
andi999 6y ago
Somehow I could never get to intermediate level in cmake. I read the book, and still clueless. Getting Cuda to run was arbitrary luck. How does one understand (modern) cmake? Read the source code?
- lasagnaphil 6y ago
  I kinda learned CMake on the fly by trying to (and sometimes failing to) use other external C++ libraries. (I’m still not an expert in it though.) Some of the packages had perfect CMake integration (find_package just works), some had to be manually compiled to a library (via add_library), and some used a custom script for installation such that I needed to write a FindXX.cmake file from scratch. You basically learn by haphazardly throwing yourself against the wall multiple times. “Modern” CMake tutorials will help to a certain extent, but the examples they use only use perfectly modern-CMake-ready libraries; real life is often more cruel than that! (especially when you’re doing 3D graphics and need to deal with all sorts of esoteric legacy systems).
MaxBarraclough 6y ago
Point 3 downplays just how awful the CMake scripting language is. It's not just ugly, it's needlessly non-standard and unintuitive, full of footguns, and can be an infuriating timesink. You should still probably use CMake, but make no mistake, sometimes it can be absolutely miserable to work with. I rambled about this recently: https://news.ycombinator.com/item?id=24203172 https://news.ycombinator.com/item?id=24203172
- CannisterFlux 6y ago
  I always think CMake is so simple, there's nothing to it. It is maybe awkward to write compared to python or whatever, and kinda ugly, but it is very easy to learn, you can do anything with it (eventually), multiplatform, and has several back-ends, like make, ninja or IDEs. The issue you linked to was changing the environment after running the "configure" step, but the availability of the header that had been newly installed was cached to "not available", so re-running cmake used the cached "not available" instead of checking the system again. Or something like that. Seems like a classic trade off of speed vs correctness. Something like SCons would always check everything and ran super slow, whereas CMake opts for not checking things that are less likely to change and caching the result. That shouldn't be used as a reason to throw away all the other good stuff CMake has :-)
- fetbaffe 6y ago
  I recently experimented with C++17/20 in CLion & CMake. I tried to organize my project that different namespaced folders could have their own cmake-file and depend on different external libraries (dlls). I gave up. CMake is just too frustrating to work with. Hard to debug, different API versions, many different ways to do the same thing, hard to understand the abstraction of CMake itself. Total time sink. I will never use that again.
  - s9w 6y ago
    > many different ways to do the same thing This is a huge problem with too many things - CMake included. Backwards compatibility is often being praised too highly.
  - 6y ago
s9w 6y ago
CMake might be the best thing we have in C++, but god does that fact tell you what we have to work with. I've never delved far into CMake, but I regularly make two observations that make my shy away: 1) Every time some "guide" gets posted on the programming communities, there's people pointing out mistakes, deprecated functions or alternatives. 2) If you look at the CMakeLists.txt files of various popular libraries, they all look different. There's some commonality but much less than what you would desire from a more or less standard build system.
- dgellow 6y ago
  Maybe what we need is a CMake linter with rules for some strong default opinions.
  - benttoothpaste 6y ago
    What we need is CMakeCMake. A special CMake for building CMake rules with its own special meta-language.
  - rurban 6y ago
    There is a cmake linter. I use it for some of the projects I inherited which still use cmake. But cmake is a joke really. Overly simplistic, but for anything close to a real project compared to autotools, autotools is much much better. With autotools you get tons of constantly improving standard probes and fixes. Cmake is only for really trivially small projects. I just added cross-compilation support for my aarch64 phones. It was doable with cmake, but it's a huge mess. With autotools it would have needed no changes at all. For cmake I need seperate CmakeCFG files. Not even talking about adding GPU support. Or valgrind. Or proper testing.
- lasagnaphil 6y ago
  1) always comes up in HN and it’s totally hilarious. Seriously I do not know (and do not care) what is the “right” way to write CMake anymore. It’s kinda like C++ where everyone has their own standards for writing code (think of Orthodox C++ vs Modern C++) but the consensus is even more scattered out in the case of CMake.
oldgradstudent 6y ago
The real reason is that CMake became a dramatical better tool just before version 3.0, and it has been improving since. That's what people call "modern CMake". The scripting language remains awful, though.
- lasagnaphil 6y ago
  Modern CMake still doesn’t have local variables or any sort of scope, functions cannot return values, and there is no thing such as a dictionary datatype. You gradually accept the shortcomings of the language though, in a typical 5-stages-of-grief fashion.
  - oldgradstudent 6y ago
    It's more of a sixth stage of grief where you discover your tragically deceased beloved relatives left you a very nice sum in their will. The language is terrible, but there are things CMake does pretty well.
deleted 6y ago
[deleted]
lightgreen 6y ago
CMake is a hell for medium/large projects. Builds are not hermetic/reproducible. When doing deep change of CMake files, the only reliable way to verify it is correct is to clean and rebuild everything. CMake is very very slow. A minor change in CMake file results in CMake re-evaluation which is very slow for large projects. CMake language is just pain. And CMake does not have cache. CCache helps a little, but it’s still much worse than cache of proper modern build system. I would probably recommend Bazel for building C++. Works like magic. Although if you hit Bazel limitations (likely you won’t but still), you don’t have many options how to deal with it. You never need to clean Bazel cache whatever you are doing (unless you are intentionally trying to break it of course).
- enriquto 6y ago
  > CMake is a hell for medium/large projects. I agree. And if you let me, I want to add that for small projects it is ridiculous overkill. This leaves no reasonable use case for cmake (except maybe building itself solipsistically for all eternity). And I like it that way.
  - lightgreen 6y ago
    CMake was a big improvement over make and autoconf years ago, but now it’s time to admit that it was a step to a wrong direction, dead end, cannot be fixed. CMake model is wrong. CMake just need to retire.
    - pmezard 6y ago
      What is the good model?
      - lightgreen 6y ago
        Bazel’s: * each build file is independent (unlike CMake where the project is one big script with global scope and side effects) * build script evaluation is hermetic (cannot read time for example) and strictly reproducible * target is rebuilt not by timestamp changes (which is unreliable for several reasons), but instead all dependencies must be declared, and target is rebuilt when the hash of dependencies change
dgellow 6y ago
CMake really need beginner proof documentation with clear information about what should someone care about when they start, and what is more advanced. I have experience with a lot of build systems in various languages, but to be honest I had a hard time trying to learn how to use CMake for simple projects that depends on a small number of libraries. I started writing down what I’m learning, and the result is a huge document with way too many details I shouldn’t be introduced to before I’m doing something way more complicated. And that was both time consuming and frustrating.
dasloop 6y ago
QMake no longer exists and the replacement is CMake. But the important thing here is that it is the only option. No other build system is a viable alternative for C ++ developers, because: - It is the industry standard - Dependency managers like vcpkg and conan use it - Is what Qt selected after killing Qbs We can discuss the many problems of CMake but in the short and medium term, the best solution is to focus on improving CMake
- pjmlp 6y ago
  On a similar note, I used to loathe Maven, coming from a well behaved use of Ant + Ivy, and nowadays exactly for those reasons (and not suffering from XML allergy) it has become my Java build system when it is me calling the shots. Point is, stick to a tool and improve it, as you say, we don't need fashion in build systems as well.
- slezyr 6y ago
  - Supports pre-compiled headers[1] There are a lot of C/C++ build systems until you need PCH. 1: https://onqtam.com/programming/2019-12-20-pch-unity-cmake-3-16/ https://onqtam.com/programming/2019-12-20-pch-unity-cmake-3-...
- otabdeveloper4 6y ago
  I've been programming C++ for 25 years and never had to use CMake in any professional context. I don't think there's any point in using CMake if you're not forced to support Windows.
- physicsguy 6y ago
  QMake hasn't actually been killed off, they're still maintaining it but there are no real updates or anything AFAIK.
geokon 6y ago
I really recommend people look into using Hunter to manage CMake dependencies. It's just a much more correct solution than the alternatives b/c your code and all your dependencies get built reproducibly with the exact same toolchain file. You also get things like namespaces and you eliminate weird issues with multiple versions of dependencies I've compared it to other alternatives (though I wrote this ages ago and it needs an update): https://geokon-gh.github.io/hunterintro.html https://geokon-gh.github.io/hunterintro.html I haven't used vcpkg - but the fact it's forcing its own toolchain file is a huge red flag. CMake is actually really not bad as long as you stick to a subset of the language (ha! sounds like C++) and just don't deal with the whole installer side of things and generator functions. That said 99% of CMake files are written incorrectly. CMakeLists.txt should be system agnostic and compiler/toolchain agnostic. It just coordinates the linking of libraries and where to find headers. All system specific magic needs to be in the toolchain files. Once you break that rule things quickly spin out of control and you get crazy CMake configuration that are a nightmare to maintain
- dgellow 6y ago
  > That said 99% of CMake files are written incorrectly. I see this repeated over and over since years. At some point if everybody is doing it wrong, either the tool is the actual issue, or there is a clear problem of miscommunication somewhere.
  - MaxBarraclough 6y ago
    In CMake, there are many ways to do it, most of them deprecated, and most of them poorly documented. If I recall correctly, even the official Find... modules rely on deprecated functionality.
  - bluGill 6y ago
    In any long lived project eventually you discover a better way and regret the past. New tools that don't have a history don't have this problem, but new tools eventually become old and have some dark corner they regret.
- lasagnaphil 6y ago
xvilka 6y ago
Would be nice if they will keep the main logic but rework the language syntax, parsing rules, etc.
mianos 6y ago
Every time I needed to look at adding something to the build system at my old job, in CMake, I booked a day. What is incredulous to me is the numerous answers on the forum and stackoverflow are never ever complete enough to be useable. All they do is give you a hint. If you want to do something, say, add some existing external library with partial cmake support built in, you check endless posts with hints until, at the end of a wasted day, you add one or two lines to your CMake files and the job is done.
- deleted 6y ago
  [deleted]
deleted 6y ago
[deleted]
dfgdghdf 6y ago
This article completely glosses over the shortcomings of CMake. It follows a fundamentally flawed design and the sooner the C++ community manages to migrate (probably to Bazel?) the better off we will all be.
Ericson2314 6y ago
CMake is horrendous. There was a reddit AMA when someone asked what the dev would change about CMake if back-compat wasn't and issue, and the dev said that hadn't thought about it. To me, that's the nail in the coffin: all engineers should think about how things ought to work, even if they cannot immediately fix it. Just use Meson and leave this POS behind.
- cromka 6y ago
  > To me, that's the nail in the coffin: all engineers should think about how things ought to work, even if they cannot immediately fix it. This has always been a bone of contention between me and my peers or leads: I always intended to drill down to the root of the problem to understand how a system should behave, while most of the time they considered it a waste of time and frustrating. "Patch with a workaround and call it a day" mentality is ubiquitous nowadays, from what I see.
  - Ericson2314 6y ago
    Well, it depends where you work, though perhaps I am a bit of an Oasis.
gjvc 6y ago
CMake is used by LLVM, and I wish it would use something with a better syntax.
egberts1 6y ago
I am a heavy CMake user (as well as Ninja, Maven, SCon, make, Gradle, premake, MakeMe, Buck, Meson, Ant and parallelized bash build tool), I’ve used CLion and PyCharm as my primary IDE but never used CMake on them anymore after a few aborted attempts. While not the IDE’s fault, CMake is that bad, starting with a “build” subdirectory. The bug report I filed with JetBrain/Idea (IDE creator of PyCharm/CLion) to make it work with Make/autotool is now the oldest bug over there. I’ll take Make and autotool/autoscan any day and StackExchange for package identification of weird dependencies.
physicsguy 6y ago
I use QMake and it's painful as hell for certain things. If you want to set certain options globally (e.g. where to look for external libraries that you don't want everything to link against), you end up having to include files all over the place just to avoid duplicating things. Building multiple executables is not possible in a single .pro file, so if you've got a folder full of unit tests, which are separate applications, you have to create a .pro file with subdirs as the author here does, and then create another pro file for each test executable.

57 points by Kelteseth 6y ago

> Also, many people hate MOC. This is the pre compiler that compiles your Qt C++ into regular C++. MOC is not a pre-compiler but a code generator; all code written by the developer is compiled as is, but it can include macros known to MOC for which additional code files are generated. This goes without notice when e.g. using qmake or cmake. No reason to hate it.

formerly_proven 6y ago

The author points out the lack of emperor's clothes when he says that the choice of build system is primarily political and not based on technical merit, since politics elevate CMake above Qbs, even though the latter is a superior build system (syntax/UX x performance x correctness).

andi999 6y ago

Somehow I could never get to intermediate level in cmake. I read the book, and still clueless. Getting Cuda to run was arbitrary luck. How does one understand (modern) cmake? Read the source code?

lasagnaphil 6y ago
I kinda learned CMake on the fly by trying to (and sometimes failing to) use other external C++ libraries. (I’m still not an expert in it though.) Some of the packages had perfect CMake integration (find_package just works), some had to be manually compiled to a library (via add_library), and some used a custom script for installation such that I needed to write a FindXX.cmake file from scratch. You basically learn by haphazardly throwing yourself against the wall multiple times. “Modern” CMake tutorials will help to a certain extent, but the examples they use only use perfectly modern-CMake-ready libraries; real life is often more cruel than that! (especially when you’re doing 3D graphics and need to deal with all sorts of esoteric legacy systems).

MaxBarraclough 6y ago

Point 3 downplays just how awful the CMake scripting language is. It's not just ugly, it's needlessly non-standard and unintuitive, full of footguns, and can be an infuriating timesink. You should still probably use CMake, but make no mistake, sometimes it can be absolutely miserable to work with. I rambled about this recently: https://news.ycombinator.com/item?id=24203172 https://news.ycombinator.com/item?id=24203172

CannisterFlux 6y ago
I always think CMake is so simple, there's nothing to it. It is maybe awkward to write compared to python or whatever, and kinda ugly, but it is very easy to learn, you can do anything with it (eventually), multiplatform, and has several back-ends, like make, ninja or IDEs. The issue you linked to was changing the environment after running the "configure" step, but the availability of the header that had been newly installed was cached to "not available", so re-running cmake used the cached "not available" instead of checking the system again. Or something like that. Seems like a classic trade off of speed vs correctness. Something like SCons would always check everything and ran super slow, whereas CMake opts for not checking things that are less likely to change and caching the result. That shouldn't be used as a reason to throw away all the other good stuff CMake has :-)
fetbaffe 6y ago
I recently experimented with C++17/20 in CLion & CMake. I tried to organize my project that different namespaced folders could have their own cmake-file and depend on different external libraries (dlls). I gave up. CMake is just too frustrating to work with. Hard to debug, different API versions, many different ways to do the same thing, hard to understand the abstraction of CMake itself. Total time sink. I will never use that again.
- s9w 6y ago
  > many different ways to do the same thing This is a huge problem with too many things - CMake included. Backwards compatibility is often being praised too highly.
- 6y ago

s9w 6y ago

CMake might be the best thing we have in C++, but god does that fact tell you what we have to work with. I've never delved far into CMake, but I regularly make two observations that make my shy away: 1) Every time some "guide" gets posted on the programming communities, there's people pointing out mistakes, deprecated functions or alternatives. 2) If you look at the CMakeLists.txt files of various popular libraries, they all look different. There's some commonality but much less than what you would desire from a more or less standard build system.

dgellow 6y ago
Maybe what we need is a CMake linter with rules for some strong default opinions.
- benttoothpaste 6y ago
  What we need is CMakeCMake. A special CMake for building CMake rules with its own special meta-language.
- rurban 6y ago
  There is a cmake linter. I use it for some of the projects I inherited which still use cmake. But cmake is a joke really. Overly simplistic, but for anything close to a real project compared to autotools, autotools is much much better. With autotools you get tons of constantly improving standard probes and fixes. Cmake is only for really trivially small projects. I just added cross-compilation support for my aarch64 phones. It was doable with cmake, but it's a huge mess. With autotools it would have needed no changes at all. For cmake I need seperate CmakeCFG files. Not even talking about adding GPU support. Or valgrind. Or proper testing.
lasagnaphil 6y ago
1) always comes up in HN and it’s totally hilarious. Seriously I do not know (and do not care) what is the “right” way to write CMake anymore. It’s kinda like C++ where everyone has their own standards for writing code (think of Orthodox C++ vs Modern C++) but the consensus is even more scattered out in the case of CMake.

oldgradstudent 6y ago

The real reason is that CMake became a dramatical better tool just before version 3.0, and it has been improving since. That's what people call "modern CMake". The scripting language remains awful, though.

lasagnaphil 6y ago
Modern CMake still doesn’t have local variables or any sort of scope, functions cannot return values, and there is no thing such as a dictionary datatype. You gradually accept the shortcomings of the language though, in a typical 5-stages-of-grief fashion.
- oldgradstudent 6y ago
  It's more of a sixth stage of grief where you discover your tragically deceased beloved relatives left you a very nice sum in their will. The language is terrible, but there are things CMake does pretty well.

deleted 6y ago

[deleted]

lightgreen 6y ago

CMake is a hell for medium/large projects. Builds are not hermetic/reproducible. When doing deep change of CMake files, the only reliable way to verify it is correct is to clean and rebuild everything. CMake is very very slow. A minor change in CMake file results in CMake re-evaluation which is very slow for large projects. CMake language is just pain. And CMake does not have cache. CCache helps a little, but it’s still much worse than cache of proper modern build system. I would probably recommend Bazel for building C++. Works like magic. Although if you hit Bazel limitations (likely you won’t but still), you don’t have many options how to deal with it. You never need to clean Bazel cache whatever you are doing (unless you are intentionally trying to break it of course).

enriquto 6y ago
> CMake is a hell for medium/large projects. I agree. And if you let me, I want to add that for small projects it is ridiculous overkill. This leaves no reasonable use case for cmake (except maybe building itself solipsistically for all eternity). And I like it that way.
- lightgreen 6y ago
  CMake was a big improvement over make and autoconf years ago, but now it’s time to admit that it was a step to a wrong direction, dead end, cannot be fixed. CMake model is wrong. CMake just need to retire.
  - pmezard 6y ago
    What is the good model?
    - lightgreen 6y ago
      Bazel’s: * each build file is independent (unlike CMake where the project is one big script with global scope and side effects) * build script evaluation is hermetic (cannot read time for example) and strictly reproducible * target is rebuilt not by timestamp changes (which is unreliable for several reasons), but instead all dependencies must be declared, and target is rebuilt when the hash of dependencies change

dgellow 6y ago

CMake really need beginner proof documentation with clear information about what should someone care about when they start, and what is more advanced. I have experience with a lot of build systems in various languages, but to be honest I had a hard time trying to learn how to use CMake for simple projects that depends on a small number of libraries. I started writing down what I’m learning, and the result is a huge document with way too many details I shouldn’t be introduced to before I’m doing something way more complicated. And that was both time consuming and frustrating.

dasloop 6y ago

QMake no longer exists and the replacement is CMake. But the important thing here is that it is the only option. No other build system is a viable alternative for C ++ developers, because: - It is the industry standard - Dependency managers like vcpkg and conan use it - Is what Qt selected after killing Qbs We can discuss the many problems of CMake but in the short and medium term, the best solution is to focus on improving CMake

pjmlp 6y ago
On a similar note, I used to loathe Maven, coming from a well behaved use of Ant + Ivy, and nowadays exactly for those reasons (and not suffering from XML allergy) it has become my Java build system when it is me calling the shots. Point is, stick to a tool and improve it, as you say, we don't need fashion in build systems as well.
slezyr 6y ago
- Supports pre-compiled headers[1] There are a lot of C/C++ build systems until you need PCH. 1: https://onqtam.com/programming/2019-12-20-pch-unity-cmake-3-16/ https://onqtam.com/programming/2019-12-20-pch-unity-cmake-3-...
otabdeveloper4 6y ago
I've been programming C++ for 25 years and never had to use CMake in any professional context. I don't think there's any point in using CMake if you're not forced to support Windows.
physicsguy 6y ago
QMake hasn't actually been killed off, they're still maintaining it but there are no real updates or anything AFAIK.

geokon 6y ago

I really recommend people look into using Hunter to manage CMake dependencies. It's just a much more correct solution than the alternatives b/c your code and all your dependencies get built reproducibly with the exact same toolchain file. You also get things like namespaces and you eliminate weird issues with multiple versions of dependencies I've compared it to other alternatives (though I wrote this ages ago and it needs an update): https://geokon-gh.github.io/hunterintro.html https://geokon-gh.github.io/hunterintro.html I haven't used vcpkg - but the fact it's forcing its own toolchain file is a huge red flag. CMake is actually really not bad as long as you stick to a subset of the language (ha! sounds like C++) and just don't deal with the whole installer side of things and generator functions. That said 99% of CMake files are written incorrectly. CMakeLists.txt should be system agnostic and compiler/toolchain agnostic. It just coordinates the linking of libraries and where to find headers. All system specific magic needs to be in the toolchain files. Once you break that rule things quickly spin out of control and you get crazy CMake configuration that are a nightmare to maintain

dgellow 6y ago
> That said 99% of CMake files are written incorrectly. I see this repeated over and over since years. At some point if everybody is doing it wrong, either the tool is the actual issue, or there is a clear problem of miscommunication somewhere.
- MaxBarraclough 6y ago
  In CMake, there are many ways to do it, most of them deprecated, and most of them poorly documented. If I recall correctly, even the official Find... modules rely on deprecated functionality.
- bluGill 6y ago
  In any long lived project eventually you discover a better way and regret the past. New tools that don't have a history don't have this problem, but new tools eventually become old and have some dark corner they regret.
lasagnaphil 6y ago

xvilka 6y ago

Would be nice if they will keep the main logic but rework the language syntax, parsing rules, etc.

mianos 6y ago

Every time I needed to look at adding something to the build system at my old job, in CMake, I booked a day. What is incredulous to me is the numerous answers on the forum and stackoverflow are never ever complete enough to be useable. All they do is give you a hint. If you want to do something, say, add some existing external library with partial cmake support built in, you check endless posts with hints until, at the end of a wasted day, you add one or two lines to your CMake files and the job is done.

deleted 6y ago
[deleted]

deleted 6y ago

[deleted]

dfgdghdf 6y ago

This article completely glosses over the shortcomings of CMake. It follows a fundamentally flawed design and the sooner the C++ community manages to migrate (probably to Bazel?) the better off we will all be.

Ericson2314 6y ago

CMake is horrendous. There was a reddit AMA when someone asked what the dev would change about CMake if back-compat wasn't and issue, and the dev said that hadn't thought about it. To me, that's the nail in the coffin: all engineers should think about how things ought to work, even if they cannot immediately fix it. Just use Meson and leave this POS behind.

cromka 6y ago
> To me, that's the nail in the coffin: all engineers should think about how things ought to work, even if they cannot immediately fix it. This has always been a bone of contention between me and my peers or leads: I always intended to drill down to the root of the problem to understand how a system should behave, while most of the time they considered it a waste of time and frustrating. "Patch with a workaround and call it a day" mentality is ubiquitous nowadays, from what I see.
- Ericson2314 6y ago
  Well, it depends where you work, though perhaps I am a bit of an Oasis.

gjvc 6y ago

CMake is used by LLVM, and I wish it would use something with a better syntax.

egberts1 6y ago

I am a heavy CMake user (as well as Ninja, Maven, SCon, make, Gradle, premake, MakeMe, Buck, Meson, Ant and parallelized bash build tool), I’ve used CLion and PyCharm as my primary IDE but never used CMake on them anymore after a few aborted attempts. While not the IDE’s fault, CMake is that bad, starting with a “build” subdirectory. The bug report I filed with JetBrain/Idea (IDE creator of PyCharm/CLion) to make it work with Make/autotool is now the oldest bug over there. I’ll take Make and autotool/autoscan any day and StackExchange for package identification of weird dependencies.

physicsguy 6y ago

I use QMake and it's painful as hell for certain things. If you want to set certain options globally (e.g. where to look for external libraries that you don't want everything to link against), you end up having to include files all over the place just to avoid duplicating things. Building multiple executables is not possible in a single .pro file, so if you've got a folder full of unit tests, which are separate applications, you have to create a .pro file with subdirs as the author here does, and then create another pro file for each test executable.