Live data from Hacker News

Everything you never wanted to know about CMake (redux)

izzys.casa

31–40 of 58 posts

Re: Everything you never wanted to know about CMake (redux)

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

Re: Everything you never wanted to know about CMake (redux)

#32

Earlier quoted context omitted.

The language itself is, in many ways, worse than the shell scripts it replaced with autoconf.

I don't disagree that the CMake language is badly misguided. I think that the SCons approach of just writing Python is sensible rather then inventing a whole new scripting language as well as a build system. But CMake probably will get you a program that compiles cross-platform within an hour or two, even for a novice. Autotools probably won't do that for you.

SCons is utterly horrible. It isn’t a build system so much as a “Build your own build system” system. It gives you absolutely nothing to manage dependencies or shared information, or cross-platform ways of handling compiler features.

As such, everything using it is it’s own unique system completely alien and not interoperable with anything else.

And being python seems to lead to people embedding parts of their application as part of the build system, so now that is intertwined also.

I will run a million miles if I ever see a project using SCons, CMake is infinitely nicer, and makes some sense but I agree with further up the thread that it needs a new, saner language that maps over the top (expressions would be a start).

Re: Everything you never wanted to know about CMake (redux)

#33
post #32

Earlier quoted context omitted.

I don't disagree that the CMake language is badly misguided. I think that the SCons approach of just writing Python is sensible rather then inventing a whole new scripting language as well as a build system. But CMake probably will get you a program that compiles cross-platform within an hour or two, even for a novice. Autotools probably won't do that for you.

SCons is utterly horrible. It isn’t a build system so much as a “Build your own build system” system. It gives you absolutely nothing to manage dependencies or shared information, or cross-platform ways of handling compiler features. As such, everything using it is it’s own unique system completely alien and not interoperable with anything else. And being python seems to lead to people embedding parts of their applic…

Hm. We had a SCons based build system around ten years back where we ran 10 different C++ compilers/toolchains for multiple native and cross build targets without any problems. Yes, we had to write some stuff on top of it, but after some systematic design, it went really smoothly.

Re: Everything you never wanted to know about CMake (redux)

#34
post #7

> 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, sin…

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

Re: Everything you never wanted to know about CMake (redux)

#35

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.

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.

Re: Everything you never wanted to know about CMake (redux)

#37
post #4

Earlier quoted context omitted.

It feels a lot more like "The beatings will continue until morale improves" to me.

Quite a lot of "Could be worse. Could be Autotools." for me.

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

Re: Everything you never wanted to know about CMake (redux)

#38
post #13

Earlier quoted context omitted.

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 alternativ…

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…

While I want a.build system to be declaritive, in the real world there is always complexity they designers didn't think of. So I need an escape to build something they didn't think of.

Though it would be nice if that thing I.build could then be declarative.

Re: Everything you never wanted to know about CMake (redux)

#40

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.

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…

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

Post reply on HN