Hacker News Reader

Comment by skohan | Hacker News Reader

What's wrong with CMake?

The language is extremely error prone. It's like they looked at Bash and thought "hmm, too safe".

Everything is a string, even lists are just semicolon-separated lists. The argument expansions rules for calling functions are literally impossible to remember. All variables are implicitly defined as empty strings. Typos silently break things. `if` is completely broken. The separation of the configure step from the build step is needlessly confusing and makes some things impossible. This is just scratching the surface.

It does have a couple of redeeming qualities: they have a pretty great versioning mechanism which allows them to make breaking changes. Though inexplicably they haven't used it to fix any fundamental flaws, only little tweaks. And most importantly it has been around for ages so loads of the many many weird C++ compilation knobs have been solved.

> It's like they looked at Bash and thought "hmm, too safe".

One of my favorite comments in a while. :-)

>The separation of the configure step from the build step is needlessly confusing and makes some things impossible.

I'm confused. How do you propose CMake supports all those build generators without doing this?

(PS. I really don't think the syntax is that bad, aside that it is jarring for C programmers, most complaints are overblown and you get used to it once you learn the rules. It might be interesting if someone made a CMake variant with a less obscure syntax but I don't see much motivation for that to actually happen)

The syntax has improved slightly in recent releases with the target family of commands. You just have to know what legacy parts to avoid which is itself a burden. Still it beats digging into the bowels of autotools.

I do fantasize about a new Cmake frontend implemented with Tcl scripting. That would be far more consistent and flexible and you can disable much of the language by default to minimize footbullets then allow commands to be reenabled for times they're needed.

I guess I just don't see where there are footguns and unsafety here. Build scripts are intended to operate on a known, fixed set of inputs.

The target commands don't change the syntax at all. And your definition of "recently" is very loose! I've been doing CMake for 6 years and always used the target versions of commands.

In my view cmake doesn't really have much of a syntax to be learned. Apart from the most basic variable- list- and function-handling.

Beyond that the difficulty lies in that calling any command lacks consistency and the output is just that some global variable without any convention were reassigned. There is no common semantics so you can not take the knowledge you learned from one operation and apply to the next one, everything is unique and non-composable. The solution to almost everything is just paste this random magic string anywhere in your cmakelist and it will work.

> How do you propose CMake supports all those build generators without doing this?

I propose that it doesn't support build generators. It should do the build itself, like QBS did.

This would remove one of the key selling points of CMake, the fact that it is "glue" to permit development with any build tool or IDE of choice.

It's great that one person can be using Visual Studio on Windows while another uses CLion on MacOS and another uses Eclipse or Emacs on Linux, all working on the same codebase. It's a huge benefit for cross-platform tooling-independent development.

There was some work ongoing to move to Lua internally and gradually move over to it, but it's a huge task and I've not kept up on recent progress with this.

This would of course be a huge improvement, but there are many details to get right to support the old and new scripts in parallel to effect a smooth transition. But in the long term, this will resolve many complaints about CMake and really improve the semantics of the language and development and debugging of scripts.

The syntax is weird and inconsistent. Built ins are case insensitive, but user defined functions are sensitive. No way to return values from functions, except by jumping to the scope of the caller and changing its variables unexpectedly. (Better hope you know what the caller does)

That isn't a complete list .

Despite the above cmake is your best choice of build system for C. Though some competitors could overtake it.

On top of that I found the documentation and the book terrible. I thought it might be easier to understand what it does by reading the source code (didn't try yet)

The documentation is "complete" in the way that some manpages are - the biggest problem with it is the lack of best practices guidance. About books, I believe that good ones exist now. The official CMake book is not among the good ones - last time I checked, it was ridiculously outdated (and IMO not even very good at the time it was written).

I have extracted some knowledge from the source code. It's more underdesigned than overdesigned and I think that's the better side to err on. Kinda awkward but you can figure it out.

Which cmake book is good?

Professional cmake seems to be the one recommended now. The author updates it regularly.

My least favorite part is how completely impossible it is to discover all the implicit variables set by other cmake files, and there's no common convention, so some libraries are like ${ZLIB_INCLUDE_DIR} and some are #{zLib_INCLUDE_DIRS} and you have to just manually try a bunch of combinations to finally find what works because the scripts themselves use weird string based metaprogramming to build the variables themselves.

which competitors?

any thoughts on why are build tools so hard to get right?

Build2 is one that a coworker of mine likes. There are others.

What makes it hard is the problem is a lot deeper than most people realize, so most attempts are not powerful enough to be useful. They are clean until someone points out one of the many edge cases that were not thought of, and by the time you support even a few of them your clean design is a mess of uglyness.

Making it worse build systems are an afterthought to most develpers so you end up with a mess just because the programers are not taking care to write good clean code in the build system.

Reply on news.ycombinator.com