An Introduction to Modern CMake | Hacker News Reader

An Introduction to Modern CMake

cliutils.gitlab.io

60 pointshighfrequency28 comments

Nice to see cliutils trending. Henry really understands CMake, so advice by him is always good to follow. I'm not a big fan of CMake, but after years of suffering, I mean, experience, I've learned how to use it relatively well. One feature I like is the "dashboard" model of ctest. It's somewhat painful to setup, but once you have it working, it makes your life building and testing your project much easier. Unfortunately, when I posted it nobody noticed, but if you want to have a really simple CI setup for your CMake project, checkout this link:

https://news.ycombinator.com/item?id=39657703

See the CI workflow using my script here: https://github.com/xrootd/xrootd/blob/master/.github/workflo...

Also, with some advice from Henry I wrote a nice new setup.py for the Python bindings of XRootD integrated with the CMake build. I didn't want a dependency in scikit-build in the end, but his advice helped me a lot.

I wanted to shout out to $(cmake --system-information) <https://cmake.org/cmake/help/v3.29/manual/cmake.1.html#cmdop...> that I discovered yesterday and really goes a long way toward helping to understand what cmake sees about the world. I don't offhand know what version introduced it, but in terms of "modern" cmake it's the one that comes with Homebrew

Feel free to make a MR, that sounds like a good tip. :)

Is there a good introduction to CMake for those of us on the receiving end, i.e., we’re trying to build a package, maintained by someone else, which uses CMake? Things like how to tell it where to find this other package that I just built (and which is not in /usr/local!), how to get proper @rpath:s installed in my .dylibs on macOS, etc?

Cmake's built-in find_package[1] often[2] just ends up using pkg-config[3] under the hood. There are a bunch of environment variables you can set to add more search paths, either to pkg-config or to CMake Find scripts. If a library isn't packaged for CMake or pkg-config, you can write a CMake package and add it to your user package registry[4].

This is, of course, a massive pain in the ass, but C & C++ library packaging is about twelve different kinds of massive pain in the ass, and CMake is easier to write than a lot of the other packaging formats, so this is a small part of it.

[1] https://cmake.org/cmake/help/latest/command/find_package.htm...

[2] https://cmake.org/cmake/help/latest/module/FindPkgConfig.htm...

[3] https://www.freedesktop.org/wiki/Software/pkg-config/

[4] https://cmake.org/cmake/help/latest/manual/cmake-packages.7....

> find_package often just ends up using pkg-config

find_package() is just a souped-up include(). What happens once it finds the script matching the criteria provided by arguments and cache variables depends entirely on the script(s) (plural, because version criterion is satisfied by the *ConfigVersion.cmake script for config mode search) it runs. The PkgConfig module is only mentioned in a couple of CMake provided find modules:

    >find -maxdepth 1 -type f -name "Find*.cmake" -not -name FindPkgConfig.cmake -exec ugrep -HFe PkgConfig {} + | cut -d: -f1 | sort | uniq | sed s/..//;s/\.cmake//
    FindBLAS
    FindCURL
    FindCurses
    FindEXPAT
    FindFontconfig
    FindGLUT
    FindGSL
    FindGnuTLS
    FindImageMagick
    FindLAPACK
    FindLibXml2
    FindLibXslt
    FindLibinput
    FindMPI
    FindOpenSP
    FindOpenSSL

The prevalent method of discovering packages is via the package provided config scripts, which of course have to come from upstream. Kitware stopped adding new find modules, because they are not worth the maintenance effort (e.g. find modules require maintaining a list of versions like for Python or Boost) and instead upstreams should provide a proper CMake package.

pkg-config also really only works in the Linux bubble. CPS[1] is trying to bridge the gap here if you are interested.

[1]: https://github.com/cps-org/cps

I dunno why you linked to the specification repo, since reading over it and its included sample made it seem like the "current editor in chief"'s fever dream of JSON all the things

Only by going up to the repo listing does one find the actual implementation that alleges to replace pkg-config however <https://github.com/cps-org/cps-config#status> seems like "well, good luck" for the problem they're trying to solve. I mean, they couldn't even write down what does or doesn't work in order to know if I should bother learning its snowflake json schema? Not even a $(cps-config --import) to port over the bazillions of .pc files out in the wild

The software distribution side of CMake is there and it serves many needs, so you can't really get a clear answer here, because only you know what you really need.

Package discovery for example can be done with the CMAKE_PREFIX_PATH[1] command line cache variable, which is a list of prefixes where find_*() commands will go looking for things. But if you are putting your own install prefix together, or are using a system prefix, then CMAKE_INSTALL_PREFIX[2] can also serve that purpose and it will also set the default install prefix for cmake --install. You can also control discovery on a per find_*() command basis using various environment and cache variables, all documented in their respective documentation. For example, see the numbered list in find_package's documentation[3].

Setting RPATH can be done at a project level using the CMAKE_INSTALL_RPATH[4] variable. However, if you have both executables and libraries in a project, you might see how that may not be the most useful approach and instead you'd want to reach for CPack scripting (via CPACK_PRE_BUILD_SCRIPTS[5]) to setup RPATH separately for things going in /bin and /lib.

Software distribution is messy and CMake provides tools to deal with things, but you have to know what's the most appropriate soltuion for your case.

[1]: https://cmake.org/cmake/help/latest/variable/CMAKE_PREFIX_PA...

[2]: https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_P...

[3]: https://cmake.org/cmake/help/latest/command/find_package.htm...

[4]: https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_R...

[5]: https://cmake.org/cmake/help/latest/module/CPack.html#variab...

I'll use "modern" and "CMake" in the same sentence once I can have true functions and not just procedures; give me a `set -u` equivalent, while at it.

> give me a `set -u` equivalent

--warn-uninitialized and -Werror=dev will do just that: https://cmake.org/cmake/help/latest/manual/cmake.1.html

This document seems antique, judging from the referenced talks and CMake versions

The C++ community moves slowly for the most part, particularly when it comes to tooling like build systems.

From a quick glance most of it looks pretty relevant to me.

Yep. Anything less than 10 years old is new & untested, anything less than 20 years old is new but probably decently common. Give a tool about 40 years to reach mass adoption (to the point that earlier tools aren't seen often).

Feel free to link to a more up-to-date tutorial

Or update things that are dated now. I’ve been mostly keeping the max version up to date but haven’t bumped the min version yet. I’d like to make it 3.11 or 3.15 in the near future.

My usual comment shilling for xmake in any build system conversation, that's how much I like it : https://xmake.io/#/

Unrelated, but why do so many modern tools tell you to curl | sh to install them? It feels so wrong to run random code from the web. Surely "get the files from here and run install.sh" is not a hard instruction to follow for a developer, right?

There are other installation methods : https://xmake.io/#/guide/installation?id=macos

It's in the official Fedora and Arch repos and there is ppa for Ubuntu

Honestly, there's no difference in practice.

You can always just curl, inspect the script, shell it.

Personally I always use AUR wrappers since I hate having programs installed outside of packages.

... What's the actual difference between these two cases in terms of security ? Downloading install.sh from Firefox won't be magically safer than downloading it from curl and I'm not going to read 2k lines of shell script every time I install a new version of cmake on a new machine

What's an install script doing in 2k lines? If it is a reasonable size, I would definitely skim through it to check that it does not mess up with my environment. Or at least that it is not an obviously malicious script.

Okay, so what happens next? It downloads and installs something which you almost certainly aren’t auditing before you install it. If you don’t trust their installer, you shouldn’t trust their code.

The reason why a vocal subcommunity gets hung up on “curl | sh” is that they aren’t comfortable accepting the degree of trust which they’re placing in so many third parties but haven’t fully accepted the implications. Saying “download the file and open it manually” is basically the same as the TSA making you throw out a water bottle – it feels like diligence even though it’s pointless.

This is why most security people are focused on things like pervasive sandboxing to contain the damage when someone makes a mistake, code-signing and revocation, and trusted third-party providers (e.g. a Linux distribution or App Store) which are more trustworthy and can possibly do things like audit every binary they ship.

it took some digging to find "does xmake use xmake" since it's down in the src folder but here's a concrete example https://github.com/xmake-io/xmake/blob/v2.8.9/core/xmake.lua and https://github.com/xmake-io/xmake/blob/v2.8.9/core/src/xmake... but I couldn't decipher what the matching .sh files do, if anything

Why? What's so special about it?

1. No DSL, it's lua 2. No build/meta-build system separation 3. It's ninja-like fast 4. Package management and plenty of perks

Reply on news.ycombinator.com