Hacker News Reader

Comment by MaxBarraclough | Hacker News Reader

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

View on HN

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.

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.

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.ht...

2: https://github.com/sbellus/json-cmake/pull/3

> 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.

> Then when you want to do anything other than a simple project, it gets crazy.

I've been using CMake for around a decade and I have to say I never experienced anything remotely similar to what you described.

Do you mind sharing a real-world example of something that you struggled with while working with CMake?

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.

> 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.

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.

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.

I've got a CMake project that builds multiple libraries that depend on different libraries.

If I remember correctly I never figured out how to get the target in a subfolder, you need the target to your dependencies.

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?

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>)

> 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?

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 :-)

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

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

Qbs

https://doc.qt.io/qbs/index.html

https://youtu.be/ZS0aWEi0338

(Unfortunately it has been deprecated)

Reply on news.ycombinator.com