Re: [dev] getting rid of cmake builds

From: Dave Blanchard <dave_AT_killthe.net>
Date: Thu, 21 Sep 2023 16:10:42 -0500

[After re-reading that email I see that I should have edited it bit better before posting:]

I've used all the mainstream build systems to build thousands of other people's software packages, and a few of my own, so I have a good idea how they each stack up from the usability department at least.

All things considered, I find that cmake is a solid build system with few corner cases and surprises. It can be scaled elegantly from the simplest projects to the largest. It's my favorite among the various options.

Not that it's perfect, but surely a damn sight nicer to work with than autotools, and better than meson also as it's not built in/dependent on Python (a bloated monstrosity itself), and is overall just less of a pain in the ass to work with. Meson has some annoying quirks and some in my opinion bad features, like automatically assuming an internet connection is available and that it's allowed to use it however it likes.

I also like ninja due to its simplicity and speed. Keep in mind that cmake can output ninja files just as easily as makefiles or other options.

I'm sympathetic to the "cmake is a huge monolith" argument, as I prefer software that is smaller and simpler when possible.

It does have a number of dependencies, but these are generally packages I want on my system anyhow. They are essentially all very basic low level libraries that any Linux workstation should already have. They are also "vendored" i.e. a copy included in the tarball in case you need them for bootstrapping purposes.

I attached an example script which one could use to bootstrap cmake in a LFS type environment during the initial tool build, or pick and choose the necessary bits in order to bootstrap a custom cmake on their own live running system.

The reason for the cmake tool's long build time which makes it seem so big and bulky is largely due to the use of later C++ standards, which will always slow the build quite a bit in any project which uses them. It's not that the code is bloated, it's that it simply takes longer to compile. The newer the standards, the slower C++ builds get. The 'mold' linker is another great example of a nice tool that just takes forever to build, despite being uncomplicated and clean code, just due to using the latest C++ standards. If cmake were written in C instead, as I wish that it were, it would compile just as fast as the 'make' tool source does.

If you want to write a cmake replacement in tight, robust, well-commented C that does most everything cmake does, at least for the use case of Linux/BSD software builds (I don't care about Windows or other platforms), I'd certainly love to give it a try; but on my own system, from the perspective of Getting Things Done, I'm happy to have cmake on my system and wish more software would use it.

Dave
Received on Thu Sep 21 2023 - 23:10:42 CEST