Hacker News Reader

Comment by IshKebab | Hacker News Reader

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.

View on HN

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

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

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

Reply on news.ycombinator.com