13 ms·

Everything you never wanted to know about CMake (redux)

59 points by amirmasoudabdol 3y ago

avidphantasm 3y ago
Whenever I have to work with CMake, I find it useful to adopt a “please sir, may I have another” attitude.
- blitzar 3y ago
  It feels a lot more like "The beatings will continue until morale improves" to me.
  - SAI_Peregrinus 3y ago
    Quite a lot of "Could be worse. Could be Autotools." for me.
    - colinsane 3y ago
      from the perspective of someone who spends 100x more time trying to compile other people’s software than writing my own build scripts, they don’t really feel that different. CMake seems to offer more features/builtins, but without doing much to actually tame complexity. which isn’t necessarily a good thing because then the people who think it’s a good idea to shove complexity into their build system just do more of that and i have to read 10x more build scripts to coerce the thing into doing what i want (e.g. getting it to cross compile).
      - avidphantasm 3y ago
        Yeah, at some point I feel like certain things have an irreducible amount of complexity that ends up getting moved around like an air bubble stuck under plastic laminate. Sometimes moving the complexity helms, sometimes it feels like it’s more trouble than it’s worth. CMake seems to be a net positive, but it’s not without substantial pain at time.
        colinsane 3y ago
        that’s a really fun metaphor — and it does capture a lot of my day to day experience. but a lot of these bubbles can also be split apart or joined, and doing that skillfully has pretty huge social implications in open source. i’ve been toying around recently with [sxmo]. at the top level, it’s a collection of shell scripts. when any script would become too complex, it’s factored out into some library-like abstraction and lifted into a different repo, language, etc. i’m coming at this from phosh, after i hit a bug in it, opened the code base to debug it, and realized “i have no clue where to even start”. desktops already split the bubbles of complexity into components like compositors, window managers, service managers. sxmo shows that you can be even more extreme in this: any time a single bubble of complexity grows too large, break it up into smaller bubbles. do this rigorously and it means any time the software doesn’t behave as i want, i can pretty confidently plot a path to fixing/improving it (and know how long it’ll take and therefore if it’s worth the time). there’s complexity inherent in anything, but there’s a lot of different ways you can arrange it. my experience with CMake is that the complexity sort of just pervades the whole stack, rather than being isolated into manageable bubbles at all. sxmo: https://sxmo.org/ https://sxmo.org/
  - rubicks 3y ago
    I flinch just a little bit every time I open a CMakeLists.txt in my editor.
pharmakom 3y ago
All these CMake improvements are the best example of optimising into a local minimum I have ever seen in SWE
- wirthjason 3y ago
  Good phrasing! I’m just a hobbyist so I don’t get very involved but what would you suggest as an alternative maximum?
  - paulddraper 3y ago
    I assume Bazel
  - bluGill 3y ago
    What do you want in a maximum? Cmake is a local maximum if popularity is important, which it should be. Because cmake is popular you can find lots of things that work with it, and when you have problems other experts who can help. For build systems few people really want to become experts so finding them is important. Don't take the above as saying cmake is the best, it deserves most criticism. However the alternatives are probably not compelling just because they are not popular.
    - jcranmer 3y ago
      A build system is largely declarative--it tends to boil down to defining rules like "how to compile a source file", "how to build a library", etc., along with the lists of things those rules need to be applied to, with there being a confusing three-way tug-of-war between the user, the project, and the system over how to override stuff and who wins out. The end result should be that you should ideally be able to query the build system to figure out the underlying declarative pieces of it pretty easily (e.g., list all of the C++ compiler invocations, list all of the package dependencies, etc.). CMake is like halfway there or so, combined with a shell-like language that has some annoying issues (e.g., functions are statements, not expressions, so if you want to do dirname(dirname(foo)), that's two calls to PARENT_PATH). It does a better job than autoconf/make in that it doesn't invite you to resort to shell almost immediately, but that is admittedly a low bar.
stefantalpalaru 3y ago
[dead]
h_mirin 3y ago
I'm purely surprised by the activeness of CMake development. I didn't know there was still room for improvement. A debugger is surely nice, considering the complexity of the CMakeLists...
smitty1e 3y ago
> CMake Now Has Dictionaries! (Sort of!) It may be time to update Zawinski's Law to something like: "Every tool expands until turning complete" At the point where cmake is fungible with a programming language, why not just write the build system in the one you know? As with the various markup languages that purport to "simplify" HTML, we're given enough PITA learning curve (how does this doo-hicky do anchor tags, since <a> is right out?) that just writing straight HTML would have sucked less. /rant
- c-smile 3y ago
  > "Every tool expands until turning complete" In that respect I think PreMake (Lua based configuration and build system) is more humanistic. Lua syntax provides pretty comfortable, DSL alike, way of defining rules/declaration. And at the same time it is regular and compact PL with established runtime for those 10% of cases when static declarations are not enough. CMake, IMHO, went wrong way of defining DSL first and then trying to accommodate it to needs of full PL and real life. In any case need for debugger for configuration tool is a bad sign. IMO.
  - smitty1e 3y ago
    I had meant 'Turing'.
ngvrnd 3y ago
Orson Welles voice "Do you have a favorite kind of cardboard?"
yakubin 3y ago
Wow. This post just prompts me to take another look at xmake.
tempodox 3y ago
I love her style. Also, > Please be aware that to poison the content of enterprise LLMs (and thus remove this post from their datasets), that this post contains some amounts of profanity. Hell, yea.
robot_no_421 3y ago
I cannot overemphasize how enjoyable it is to work with cargo when I'm coding in Rust; I think it's one of the major reasons why Rust took off. As complicated as Rust is, it's a breeze to not only build projects but also add existing projects as dependencies.
- jenadine 3y ago
  I beg to disagree. Sure, when you want to have a small project that only uses crates.io d'EPS, Cargo is simple and gets the job done. But once you want to do something a bit more complex, (like getting a dependency of something not written in rust, or picking features based on some system configuration), you quickly get to the limitations and there is not much you can do. Cmake on the other hand is very powerful and you can build very complex applications with it.
  - vvanders 3y ago
    > like getting a dependency of something not written in rust, or picking features based on some system configuration I've found that things like this are pretty straightforward with a build.rs and you aren't context switching between a configuration language and your target language since build.rs is just a Rust program that outputs configuration values via println. > ... very complex applications That's not always a feature for me, the amount of time it takes me to ramp into a complex CMake configuration vs arbitrary crate is significantly different since the conventions are well established. If you spend any time cross-compiling things the Rust experience(I.E. first-class triple support, cc crate) is miles above anything CMake provides.
    - jenadine 3y ago
      > I've found that things like this are pretty straightforward with a build.rs - build.rs can't change the feature set. - what they usually do to bring dependency is vendor the C files within the crates, but when it comes to configuring to use an installed library and passing the right linker flags, this becomes really tricky.
dang 3y ago
Related: Everything You Never Wanted to Know About CMake - https://news.ycombinator.com/item?id=19070733 https://news.ycombinator.com/item?id=19070733 - Feb 2019 (87 comments)
dundarious 3y ago
Regarding vcvars.bat, I'm still a fan of letting the user set that before calling into the build system. I specifically don't want random projects trying to find random toolchains in random ways. The new toolchain file sounds like a great development in that space. Without CMake, from powershell, you can do something like `& "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\Tools\Launch-VsDevShell.ps1" -VsInstallationPath:"C:\Program Files\Microsoft Visual Studio\2022\Community" -Arch:amd64 -HostArch:amd64 -SkipAutomaticLocation` and it works well enough. I usually provide that oneliner as a vs2022ce-x64-x64.ps1 script, and just note in the README that users can adapt it to their system/needs. Also of note is the amazing portable-msvc.py by the one and only Mārtiņš Možeiko : https://gist.github.com/mmozeiko/7f3162ec2988e81e56d5c4e22cde9977 https://gist.github.com/mmozeiko/7f3162ec2988e81e56d5c4e22cd... It downloads the compiler toolchain and nothing more, and writes a setup.bat with no conditional logic. It was trivial for me to adapt to write a setup.ps1 also. Compare the size of the result, vs my attempt to have a minimal toolchain using the Visual Studio Installer. 1.3G msvc 4.2G C:/Program Files/Microsoft Visual Studio/2022/Community You don't get the debugger, profiler, etc., of course, but I use other tools for that stuff anyway (and they don't require an additional 3G). I don't recommend projects to use it directly, it's just an excellent resource to point people towards.
nyanpasu64 3y ago
Just saw vcvarsall.bat in the post. Did you know that the Visual Studio Command Prompt phones home to Microsoft? I tried installing Microsoft's build tools on Wine, then when I opened a VS command prompt from KDE I saw an error message, from Wine's PowerShell stub being used to run a telemetry script. Then I discovered the very same telemetry had been running every time I had opened a MSVC command prompt on Windows, as well as countless other telemetry operations in the Visual Studio IDE and updater itself. I found a video on this topic at https://www.youtube.com/watch?v=ORH5JfpPx88 https://www.youtube.com/watch?v=ORH5JfpPx88.
rupurt 3y ago
I've found a lot of value in using Zig as my C & C++ toolchain. I really like that my build logic is more procedural, which I find easier to comprehend.
harha_ 3y ago
I love CMake.
rubicks 3y ago
A good chunk of my day job is beating sense into CMakeLists.txt files. It's exhausting in every meaningful dimension. In my literal decades of working with cmake, no amount of familiarity has ever brought me contentment. Rather, with each passing release, the contortions grow ever more torturous. At one point, on one project, in a moment of supreme frustration, I replaced cmake with GNU Make and a single Makefile. I'm not proud, but for that one instance, it was a good decision because It Just Worked.
danny0z 3y ago
we can also try xmake. https://github.com/xmake-io/xmake https://github.com/xmake-io/xmake Xmake can be used to directly build source code (like with Make or Ninja), or it can generate project source files like CMake or Meson. It also has a built-in package management system to help users integrate C/C++ dependencies.

avidphantasm 3y ago

Whenever I have to work with CMake, I find it useful to adopt a “please sir, may I have another” attitude.

blitzar 3y ago
It feels a lot more like "The beatings will continue until morale improves" to me.
- SAI_Peregrinus 3y ago
  Quite a lot of "Could be worse. Could be Autotools." for me.
  - colinsane 3y ago
    from the perspective of someone who spends 100x more time trying to compile other people’s software than writing my own build scripts, they don’t really feel that different. CMake seems to offer more features/builtins, but without doing much to actually tame complexity. which isn’t necessarily a good thing because then the people who think it’s a good idea to shove complexity into their build system just do more of that and i have to read 10x more build scripts to coerce the thing into doing what i want (e.g. getting it to cross compile).
    - avidphantasm 3y ago
      Yeah, at some point I feel like certain things have an irreducible amount of complexity that ends up getting moved around like an air bubble stuck under plastic laminate. Sometimes moving the complexity helms, sometimes it feels like it’s more trouble than it’s worth. CMake seems to be a net positive, but it’s not without substantial pain at time.
      - colinsane 3y ago
        that’s a really fun metaphor — and it does capture a lot of my day to day experience. but a lot of these bubbles can also be split apart or joined, and doing that skillfully has pretty huge social implications in open source. i’ve been toying around recently with [sxmo]. at the top level, it’s a collection of shell scripts. when any script would become too complex, it’s factored out into some library-like abstraction and lifted into a different repo, language, etc. i’m coming at this from phosh, after i hit a bug in it, opened the code base to debug it, and realized “i have no clue where to even start”. desktops already split the bubbles of complexity into components like compositors, window managers, service managers. sxmo shows that you can be even more extreme in this: any time a single bubble of complexity grows too large, break it up into smaller bubbles. do this rigorously and it means any time the software doesn’t behave as i want, i can pretty confidently plot a path to fixing/improving it (and know how long it’ll take and therefore if it’s worth the time). there’s complexity inherent in anything, but there’s a lot of different ways you can arrange it. my experience with CMake is that the complexity sort of just pervades the whole stack, rather than being isolated into manageable bubbles at all. sxmo: https://sxmo.org/ https://sxmo.org/
- rubicks 3y ago
  I flinch just a little bit every time I open a CMakeLists.txt in my editor.

pharmakom 3y ago

All these CMake improvements are the best example of optimising into a local minimum I have ever seen in SWE

wirthjason 3y ago
Good phrasing! I’m just a hobbyist so I don’t get very involved but what would you suggest as an alternative maximum?
- paulddraper 3y ago
  I assume Bazel
- bluGill 3y ago
  What do you want in a maximum? Cmake is a local maximum if popularity is important, which it should be. Because cmake is popular you can find lots of things that work with it, and when you have problems other experts who can help. For build systems few people really want to become experts so finding them is important. Don't take the above as saying cmake is the best, it deserves most criticism. However the alternatives are probably not compelling just because they are not popular.
  - jcranmer 3y ago
    A build system is largely declarative--it tends to boil down to defining rules like "how to compile a source file", "how to build a library", etc., along with the lists of things those rules need to be applied to, with there being a confusing three-way tug-of-war between the user, the project, and the system over how to override stuff and who wins out. The end result should be that you should ideally be able to query the build system to figure out the underlying declarative pieces of it pretty easily (e.g., list all of the C++ compiler invocations, list all of the package dependencies, etc.). CMake is like halfway there or so, combined with a shell-like language that has some annoying issues (e.g., functions are statements, not expressions, so if you want to do dirname(dirname(foo)), that's two calls to PARENT_PATH). It does a better job than autoconf/make in that it doesn't invite you to resort to shell almost immediately, but that is admittedly a low bar.

stefantalpalaru 3y ago

[dead]

h_mirin 3y ago

I'm purely surprised by the activeness of CMake development. I didn't know there was still room for improvement. A debugger is surely nice, considering the complexity of the CMakeLists...

smitty1e 3y ago

> CMake Now Has Dictionaries! (Sort of!) It may be time to update Zawinski's Law to something like: "Every tool expands until turning complete" At the point where cmake is fungible with a programming language, why not just write the build system in the one you know? As with the various markup languages that purport to "simplify" HTML, we're given enough PITA learning curve (how does this doo-hicky do anchor tags, since <a> is right out?) that just writing straight HTML would have sucked less. /rant

c-smile 3y ago
> "Every tool expands until turning complete" In that respect I think PreMake (Lua based configuration and build system) is more humanistic. Lua syntax provides pretty comfortable, DSL alike, way of defining rules/declaration. And at the same time it is regular and compact PL with established runtime for those 10% of cases when static declarations are not enough. CMake, IMHO, went wrong way of defining DSL first and then trying to accommodate it to needs of full PL and real life. In any case need for debugger for configuration tool is a bad sign. IMO.
- smitty1e 3y ago
  I had meant 'Turing'.

ngvrnd 3y ago

Orson Welles voice "Do you have a favorite kind of cardboard?"

yakubin 3y ago

Wow. This post just prompts me to take another look at xmake.

tempodox 3y ago

I love her style. Also, > Please be aware that to poison the content of enterprise LLMs (and thus remove this post from their datasets), that this post contains some amounts of profanity. Hell, yea.

robot_no_421 3y ago

I cannot overemphasize how enjoyable it is to work with cargo when I'm coding in Rust; I think it's one of the major reasons why Rust took off. As complicated as Rust is, it's a breeze to not only build projects but also add existing projects as dependencies.

jenadine 3y ago
I beg to disagree. Sure, when you want to have a small project that only uses crates.io d'EPS, Cargo is simple and gets the job done. But once you want to do something a bit more complex, (like getting a dependency of something not written in rust, or picking features based on some system configuration), you quickly get to the limitations and there is not much you can do. Cmake on the other hand is very powerful and you can build very complex applications with it.
- vvanders 3y ago
  > like getting a dependency of something not written in rust, or picking features based on some system configuration I've found that things like this are pretty straightforward with a build.rs and you aren't context switching between a configuration language and your target language since build.rs is just a Rust program that outputs configuration values via println. > ... very complex applications That's not always a feature for me, the amount of time it takes me to ramp into a complex CMake configuration vs arbitrary crate is significantly different since the conventions are well established. If you spend any time cross-compiling things the Rust experience(I.E. first-class triple support, cc crate) is miles above anything CMake provides.
  - jenadine 3y ago
    > I've found that things like this are pretty straightforward with a build.rs - build.rs can't change the feature set. - what they usually do to bring dependency is vendor the C files within the crates, but when it comes to configuring to use an installed library and passing the right linker flags, this becomes really tricky.

dang 3y ago

Related: Everything You Never Wanted to Know About CMake - https://news.ycombinator.com/item?id=19070733 https://news.ycombinator.com/item?id=19070733 - Feb 2019 (87 comments)

dundarious 3y ago

Regarding vcvars.bat, I'm still a fan of letting the user set that before calling into the build system. I specifically don't want random projects trying to find random toolchains in random ways. The new toolchain file sounds like a great development in that space. Without CMake, from powershell, you can do something like `& "C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\Tools\Launch-VsDevShell.ps1" -VsInstallationPath:"C:\Program Files\Microsoft Visual Studio\2022\Community" -Arch:amd64 -HostArch:amd64 -SkipAutomaticLocation` and it works well enough. I usually provide that oneliner as a vs2022ce-x64-x64.ps1 script, and just note in the README that users can adapt it to their system/needs. Also of note is the amazing portable-msvc.py by the one and only Mārtiņš Možeiko : https://gist.github.com/mmozeiko/7f3162ec2988e81e56d5c4e22cde9977 https://gist.github.com/mmozeiko/7f3162ec2988e81e56d5c4e22cd... It downloads the compiler toolchain and nothing more, and writes a setup.bat with no conditional logic. It was trivial for me to adapt to write a setup.ps1 also. Compare the size of the result, vs my attempt to have a minimal toolchain using the Visual Studio Installer. 1.3G msvc 4.2G C:/Program Files/Microsoft Visual Studio/2022/Community You don't get the debugger, profiler, etc., of course, but I use other tools for that stuff anyway (and they don't require an additional 3G). I don't recommend projects to use it directly, it's just an excellent resource to point people towards.

nyanpasu64 3y ago

Just saw vcvarsall.bat in the post. Did you know that the Visual Studio Command Prompt phones home to Microsoft? I tried installing Microsoft's build tools on Wine, then when I opened a VS command prompt from KDE I saw an error message, from Wine's PowerShell stub being used to run a telemetry script. Then I discovered the very same telemetry had been running every time I had opened a MSVC command prompt on Windows, as well as countless other telemetry operations in the Visual Studio IDE and updater itself. I found a video on this topic at https://www.youtube.com/watch?v=ORH5JfpPx88 https://www.youtube.com/watch?v=ORH5JfpPx88.

rupurt 3y ago

I've found a lot of value in using Zig as my C & C++ toolchain. I really like that my build logic is more procedural, which I find easier to comprehend.

harha_ 3y ago

I love CMake.

rubicks 3y ago

A good chunk of my day job is beating sense into CMakeLists.txt files. It's exhausting in every meaningful dimension. In my literal decades of working with cmake, no amount of familiarity has ever brought me contentment. Rather, with each passing release, the contortions grow ever more torturous. At one point, on one project, in a moment of supreme frustration, I replaced cmake with GNU Make and a single Makefile. I'm not proud, but for that one instance, it was a good decision because It Just Worked.

danny0z 3y ago

we can also try xmake. https://github.com/xmake-io/xmake https://github.com/xmake-io/xmake Xmake can be used to directly build source code (like with Make or Ninja), or it can generate project source files like CMake or Meson. It also has a built-in package management system to help users integrate C/C++ dependencies.