Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything You Never Wanted to Know About CMake

izzys.casa

Post reply on HN
Print view View original

21–30 of 91 posts

Re: Everything You Never Wanted to Know About CMake

#21

Post by bch »

daenz wrote: post #10
whatshisface wrote: post #5

Earlier quoted context omitted.

I'm not sure what you mean. If for whatever reason I need to set up a big C/C++ application so that it can compile on diverse systems, CMake is one of my best bets for getting that to happen. If anyone would like to suggest a better option I would gladly switch, but as it stands I think CMake is pretty useful to know about.

I'm not arguing that it doesn't do what it was designed to do. I'm arguing that it is a grotesque DSL with bizarre design choices. CMake would have been better off as a cross-platform library that didn't re-invent concepts that other programming languages have already gotten correct, and instead focused on making the build system be cross-platform.

I’ve mentioned the same thing before and ironically, CMake was developed in the course of building medical imaging software[0] that was using Tcl, a flexible, embeddable language, but then decided to roll their own ad hoc language in this case. They left a LOT on the table with that decision, I think.

[0] https://en.wikipedia.org/wiki/VTK

Re: Everything You Never Wanted to Know About CMake

#23

Post by sysprogs »

Turns out I'm not alone who spent considerable time fighting with CMake configuration issues. I ended up patching it to support a basic debug server protocol, so you could step through the CMakeLists.txt files in a debugger. In case anyone's interested, here's the CMake fork with debug support [0] and there's a detailed tutorial [1].

[0] https://github.com/sysprogs/cmake

[1] https://visualgdb.com/tutorials/cmake/debugger/

Re: Everything You Never Wanted to Know About CMake

#24

Post by kuschku »

vvanders wrote: post #16
whatshisface wrote: post #14

Earlier quoted context omitted.

If the build system was a library called from a popular scripting language, it would only take a few minutes of reading the API docs before it builds could be modified. Also, there is a niche for new build systems: one-off projects that "don't matter." If you want to introduce a new build system, your first target market could be throwaway point-a-to-point-b projects and then you could expand outwards from there.

That's basically Gradle and if you think cmake is bad you haven't seen some of monstrosities that can be created when you open up a whole programming language. From what I've seen cargo gets most of the parts right. You can have a programmatic pre-build script bit can't take over the whole building process.

Yes, with gradle you can create true monstrosities — and even my own projects aren’t free of those, sadly, because sometimes there’s just no alternatives.

Here’s a few examples:

Dynamically using git describe to determine version and build number (which is actually just the # of commits that ever occured, to allow reproducable builds)

    versionCode = cmd("git", "rev-list", "--count", "HEAD")?.toIntOrNull() ?: 1
    versionName = cmd("git", "describe", "--always", "--tags", "HEAD") ?: "1.0.0"
Putting git infos into certain classes

    buildConfigField("String", "GIT_HEAD", "\"${cmd("git", "rev-parse", "HEAD") ?: ""}\"")
    buildConfigField("String", "FANCY_VERSION_NAME", "\"${fancyVersionName() ?: ""}\"")
    buildConfigField("long", "GIT_COMMIT_DATE", "${cmd("git", "show", "-s", "--format=%ct") ?: 0}L")
Using string interpolation to change the output file to include the version

    setProperty("archivesBaseName", "Quasseldroid-$versionName")
But the worst part is that often on StackOverflow you only find ugly hacks adding custom tasks, removing tasks, modifying them, etc with ugly hacks.

And even worse, sometimes there’s just no good alternative at all.

Which is why gradle took so long to clean up some parts of their API, or introduce parallel builds.

Re: Everything You Never Wanted to Know About CMake

#25

Post by weberc2 »

amelius wrote: post #15
daenz wrote: post #2

I want to upvote this for solid info, but I want to flag it so fewer people have to know about CMake. It blows my mind that experienced software developers would develop yet another pseudo-language DSL vs creating a portable library (python, java, go, whatever) that has a sensible interface.

I think a build system should always allow to convert its build description to a bash file that contains a more or less linear account of all actions needed (without support for incremental builds). Now if every library were distributed with such linear script, the user is guaranteed not to get stuck in obscure build problems. And of course, they can first try the official incremental route (cmake in this case) if th…

Maybe but bash is hardly less weird than cmake, especially for Windows devs.

Re: Everything You Never Wanted to Know About CMake

#26

Post by AlexandrB »

I don't get the hate for CMake. It has several useful advantages over plain makefiles:

* It's meant to be cross-platform, so a well structured CMake file will work in Windows.

* CMake modules allow you to include source-based libraries without a lot of drama. This is especially useful for cross-compiling or embedded use-cases.

* Out-of-source builds are supported with no additional work on my part. This is great for CI generating debug, release, and other build variants from a single cloned repository.

Re: Everything You Never Wanted to Know About CMake

#28

Post by 7e »

rough-sea wrote: post #12
ramr wrote: post #9

Earlier quoted context omitted.

Bazel works very well for C++ applicatios. Cross platform builds are well supported.

bazel can’t even build static libraries https://github.com/bazelbuild/bazel/issues/1920

False. The bug above represents a nuanced case.

Re: Everything You Never Wanted to Know About CMake

#29

Post by nerdponx »

zaphar wrote: post #22

The thing I want most from a build tool is not a nice DSL or portability. What u want most is hermetic builds. There are only a few told out there that do it. CMake is not one of them.

What do you mean "hermetic" in this context, and why does CMake fail?

Also, for my purposes (using both Windows and GNU/Linux at work), portability is a tremendous benefit.

Post reply on HN