5 ms·

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

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.
- lasagnaphil 6y ago
  Totally understand you. I once tried to use CMake by creating a hierarchy of a bunch of git submodules for my dependencies with their own CMakeLists.txt, and it failed epically. One of the main problems arose when two different submodules depended on different versions of another submodule, which really confused the hell out of CMake.
- daemin 6y ago
  For me the biggest hurdle is the disconnect between the way CMake and Visual Studio see the world. I still use it but I have my own batch files for preparing the environment, installing the dependencies, and building the CMake files in a directory outside my source tree. CMake you run to generate files that will build your thing in a single configuration (platform, runtime settings, etc). Visual Studio wants to have a solution where you can switch between many configurations (platforms, runtime etc). Yes, I have looked into latest Visual Studio CMake integration but it doesn't suit my needs because it puts the build files in some arbitrary hidden random location on disk.
- de_watcher 6y ago
  I've got a CMake project that builds multiple libraries that depend on different libraries.
  - fetbaffe 6y ago
    If I remember correctly I never figured out how to get the target in a subfolder, you need the target to your dependencies.
    - barumi 6y ago
      I don't understand. To do that you just need to pass the subdir with your CMakeLists.txt to add_subdirectory(). Exactly which problems did you experienced?
      - fetbaffe 6y ago
        Looking at it now, I wanted to copy files into the build folder after build step was done with add_custom_command() with copy_if_different and with target TARGET <project> POST_BUILD, but when I would put that in a subdirectory it wouldn't work because there was no target. add_custom_command(TARGET project POST_BUILD COMMAND ${CMAKE_COMMAND} -E copy_if_different some.dll $<TARGET_FILE_DIR:project>)
- barumi 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). What's hard about that? You have a subproject per folder, in each subproject you specify the build targets and dependencies, and then you just specify build precedence in downstream libraries when need. Exactly which problems did you experienced getting this to work?
vnorilo 6y ago
CMake punishes you whenever you choose to do anything which in the configure/build step that is not blindigly obvious, adding friction to all the crazy stunts one might dream up. This a language an evil genius might come up with while trying to do good. Of course it sucks when you actually need something nontrivial. Saying this as a heavy CMake user with a strong love and stronger hate relationship with it.
- colejohnson66 6y ago
  I tried learning CMake and it seemed so simple at first compared to, say, autotools, or even writing one’s own Makefile. Then when you want to do anything other than a simple project, it gets crazy. It’s like it was initially just an informational file format that had scripting bolted on in a haphazard manner so as not to break anything. Doesn’t CMake not even have a concept of arrays? I remember reading that functions to generate arrays were really just fancy string concatenaters with quote escaping.
  - vnorilo 6y ago
    Yes, which leads to beautiful things like `LIST_SEPARATOR` [1]. Lists in CMake are just strings with ';' as item separator. All this is just a gentle slap on the wrist for programming in your build system. Or doing something weird like optimizing a CMake-language JSON parser for performance [2]. 1: https://cmake.org/cmake/help/v3.16/module/ExternalProject.html#index-1-command:externalproject_add_step https://cmake.org/cmake/help/v3.16/module/ExternalProject.ht... 2: https://github.com/sbellus/json-cmake/pull/3 https://github.com/sbellus/json-cmake/pull/3
    - MaxBarraclough 6y ago
      > All this is just a gentle slap on the wrist for programming in your build system That's an awfully polite way of saying Yes, the CMake scripting language is indeed terrible. It's meant to be used for complex package-detection logic. CMake Find modules can run hundreds of lines. It's not unreasonable to expect proper support for arrays, proper functions that can return values, a sane syntax, etc.
nickysielicki 6y ago
What would you use instead? What does a bleeding-edge modern C++ build system look like? conan + meson?
- MaxBarraclough 6y ago
  I'm not suggesting it's a good idea to drop CMake for one of its obscure rivals, that's why I put You should still probably use CMake. I don't want to have to learn an obscure build-system to work on someone's project, and I won't ask others to do the same for me. To revisit the points I made in the old thread [0]: We pay a price for fragmentation; it's better we all agree on one system. (Although I think it's fair to say that autotools has had its time in the sun at this point, I don't see a big problem in using it for Unix-only projects.) CMake can work very well, with impressive portability, if a project's CMake scripts are rock-solid. I plan to continue to use CMake, despite its considerable shortcomings. If CMake did the following things, I could probably forgive the atrocious scripting language: 1. Overhaul the documentation. Every unit of documentation should be accompanied by an illustrative example; dry rambling essays are not the right format. Do what Microsoft do with their .Net documentation. 2. Official design-patterns for common tasks like Find modules. They shouldn't each have a character of their own. These scripts ought to be very consistent, very boilerplate-driven, and very boring. 3. Rework the officially bundled CMake scripts so that they all follow the current best-practices to the letter. As it stands, there's nowhere to go to see what real CMake scripts are meant to look like. I would suggest a linter/improved errors and warnings, but I don't know if that's practical. I would suggest replacing the entire scripting language with something less awful, but it wouldn't do to throw out compatibility. Stability is a must-have for this kind of thing. [0] https://news.ycombinator.com/item?id=24209573 https://news.ycombinator.com/item?id=24209573
- 0xabe 6y ago
  Qbs https://doc.qt.io/qbs/index.html https://doc.qt.io/qbs/index.html https://youtu.be/ZS0aWEi0338 https://youtu.be/ZS0aWEi0338 (Unfortunately it has been deprecated)

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.
lasagnaphil 6y ago
Totally understand you. I once tried to use CMake by creating a hierarchy of a bunch of git submodules for my dependencies with their own CMakeLists.txt, and it failed epically. One of the main problems arose when two different submodules depended on different versions of another submodule, which really confused the hell out of CMake.
daemin 6y ago
For me the biggest hurdle is the disconnect between the way CMake and Visual Studio see the world. I still use it but I have my own batch files for preparing the environment, installing the dependencies, and building the CMake files in a directory outside my source tree. CMake you run to generate files that will build your thing in a single configuration (platform, runtime settings, etc). Visual Studio wants to have a solution where you can switch between many configurations (platforms, runtime etc). Yes, I have looked into latest Visual Studio CMake integration but it doesn't suit my needs because it puts the build files in some arbitrary hidden random location on disk.
de_watcher 6y ago
I've got a CMake project that builds multiple libraries that depend on different libraries.
- fetbaffe 6y ago
  If I remember correctly I never figured out how to get the target in a subfolder, you need the target to your dependencies.
  - barumi 6y ago
    I don't understand. To do that you just need to pass the subdir with your CMakeLists.txt to add_subdirectory(). Exactly which problems did you experienced?
    - fetbaffe 6y ago
      Looking at it now, I wanted to copy files into the build folder after build step was done with add_custom_command() with copy_if_different and with target TARGET <project> POST_BUILD, but when I would put that in a subdirectory it wouldn't work because there was no target. add_custom_command(TARGET project POST_BUILD COMMAND ${CMAKE_COMMAND} -E copy_if_different some.dll $<TARGET_FILE_DIR:project>)
barumi 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). What's hard about that? You have a subproject per folder, in each subproject you specify the build targets and dependencies, and then you just specify build precedence in downstream libraries when need. Exactly which problems did you experienced getting this to work?

vnorilo 6y ago

CMake punishes you whenever you choose to do anything which in the configure/build step that is not blindigly obvious, adding friction to all the crazy stunts one might dream up. This a language an evil genius might come up with while trying to do good. Of course it sucks when you actually need something nontrivial. Saying this as a heavy CMake user with a strong love and stronger hate relationship with it.

colejohnson66 6y ago
I tried learning CMake and it seemed so simple at first compared to, say, autotools, or even writing one’s own Makefile. Then when you want to do anything other than a simple project, it gets crazy. It’s like it was initially just an informational file format that had scripting bolted on in a haphazard manner so as not to break anything. Doesn’t CMake not even have a concept of arrays? I remember reading that functions to generate arrays were really just fancy string concatenaters with quote escaping.
- vnorilo 6y ago
  Yes, which leads to beautiful things like `LIST_SEPARATOR` [1]. Lists in CMake are just strings with ';' as item separator. All this is just a gentle slap on the wrist for programming in your build system. Or doing something weird like optimizing a CMake-language JSON parser for performance [2]. 1: https://cmake.org/cmake/help/v3.16/module/ExternalProject.html#index-1-command:externalproject_add_step https://cmake.org/cmake/help/v3.16/module/ExternalProject.ht... 2: https://github.com/sbellus/json-cmake/pull/3 https://github.com/sbellus/json-cmake/pull/3
  - MaxBarraclough 6y ago
    > All this is just a gentle slap on the wrist for programming in your build system That's an awfully polite way of saying Yes, the CMake scripting language is indeed terrible. It's meant to be used for complex package-detection logic. CMake Find modules can run hundreds of lines. It's not unreasonable to expect proper support for arrays, proper functions that can return values, a sane syntax, etc.

nickysielicki 6y ago

What would you use instead? What does a bleeding-edge modern C++ build system look like? conan + meson?

MaxBarraclough 6y ago
I'm not suggesting it's a good idea to drop CMake for one of its obscure rivals, that's why I put You should still probably use CMake. I don't want to have to learn an obscure build-system to work on someone's project, and I won't ask others to do the same for me. To revisit the points I made in the old thread [0]: We pay a price for fragmentation; it's better we all agree on one system. (Although I think it's fair to say that autotools has had its time in the sun at this point, I don't see a big problem in using it for Unix-only projects.) CMake can work very well, with impressive portability, if a project's CMake scripts are rock-solid. I plan to continue to use CMake, despite its considerable shortcomings. If CMake did the following things, I could probably forgive the atrocious scripting language: 1. Overhaul the documentation. Every unit of documentation should be accompanied by an illustrative example; dry rambling essays are not the right format. Do what Microsoft do with their .Net documentation. 2. Official design-patterns for common tasks like Find modules. They shouldn't each have a character of their own. These scripts ought to be very consistent, very boilerplate-driven, and very boring. 3. Rework the officially bundled CMake scripts so that they all follow the current best-practices to the letter. As it stands, there's nowhere to go to see what real CMake scripts are meant to look like. I would suggest a linter/improved errors and warnings, but I don't know if that's practical. I would suggest replacing the entire scripting language with something less awful, but it wouldn't do to throw out compatibility. Stability is a must-have for this kind of thing. [0] https://news.ycombinator.com/item?id=24209573 https://news.ycombinator.com/item?id=24209573
0xabe 6y ago
Qbs https://doc.qt.io/qbs/index.html https://doc.qt.io/qbs/index.html https://youtu.be/ZS0aWEi0338 https://youtu.be/ZS0aWEi0338 (Unfortunately it has been deprecated)