[tux1968]

The recommended compatibility boilerplate for new projects is tedious. There must be a way to include this knowledge in cmake itself rather than requiring every "properly" configured project to get this right:

  cmake_minimum_required(VERSION 3.1)

  if(${CMAKE_VERSION} VERSION_LESS 3.12)
    cmake_policy(VERSION ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION})
  else()
    cmake_policy(VERSION 3.12)
  endif()

This is all before you even start thinking about your own project.

[quietbritishjim]

Why do this? Why not choose a minimum version that has the features your build system depends on and just leave the first line at the top?

It's not like you can use features from the newer version anyway, if you seriously want to support the older version. And if the same line of code has two different meanings in two versions, you want the old meaning (as you would get without target_version(<new version>)) because presumably you wrote your CMakeLists assuming that behaviour.

Edit: If I had read TFA before I posted I would've seen that's where the quoted code comes from. As the first thing that it teaches you to put in your CMakeLists.txt that is a pretty unfortunate failure IMO. If an old version of CMake has a behaviour you don't want (such as "wrong linking behavior on macOS" quoted in the linked article) then bite the bullet and use a newer minimum version of CMake. You could do this on only the cases it would cause a problem (e.g. just on MacOS, or just when a cache variable is set) but do so unconditionally of the version, so if someone tries to use an old version of CMake in that configuration they'll get a hard error. That's what you want!

[baby]

This syntax is also uber ugly. I can’t understand why C still hasn’t a proper build system that is either using convention over configuration (like Go or Rust) or something like cmake but with a proper syntax (maybe something in pyhon?)

[zeotroph]

The syntax... `list(GET mylist 4 val)` - oh, you mean `val = mylist[4]`. And the strange `function(ARGUMENTNAME argument1 OTHERARG arg2)` function syntax, and that out value names are always passed into a function as this language does not know `=` assignment, and the semicolon separated lists. And worst of all, the weak to absent typing, reading from a nonsense variable never fails.

I hope this is all abstracted enough so one day cmake can become saner to read and write. For now you just have to carry this otherwise useless syntax knowledge with you, or switch to meson or waf. Most IDEs seem to prefer cmake though, especially with the new cmake server mode it might be here to stay.

And a big thanks to all the saints who want to make cmake understandable for the rest of us.

[kabdib]

For a domain-specific language, CMAKE is a total failure at making things clearer and simpler and more reliable.

And of course the wizened software engineer in me has to be restrained: "Oh hey, I can make a better build system than that..."

[matheusmoreira]

Why restrain oneself from starting an interesting project?

[kabdib]

The world is full of interesting projects, and you have to do triage or go crazy with too many things to work on. While I have a fair amount of experience with build systems (starting with a public domain version of make that I wrote in the early 1980s for Vax/VMS and MSDOS), it's not something that I want to spend a couple years on.

On the other hand, I complain enough about CMake, Gradle and similar tools that maybe I should. I've got some ideas to try out . . . . :-)

[matheusmoreira]

It'd be nice to see those ideas realized. I have some ideas myself but haven't started anything yet because I've been focusing on my studies. I already have one small project that I work on in my free time.

My problem with most build systems is they're general purpose tools. I need to teach them how my projects work every single time. It'd be so much nicer if I could encode my conventions on the system itself.

Starting a new project should be as easy as initializing a git repository and putting the right files in the right directories. The build system should be able to at least figure out where the sources are based on convention and determine the dependencies between files.

[arbie]

Because making a new build automation system is akin to making a new standard. Or trying to build a better mousetrap.

[codetrotter]

I’ve used a few different build systems over time. A handful of them I’ve found quite agreeable, others not so much.

I once even went as far as writing a rudimentary build system from scratch myself for use in one of my personal projects. In that particular case, implementing my own build system turned out to be the right choice, but I also gained some insight into just how difficult it is to create a good build system so I would like to echo your sentiment about thanking the people that spend time developing fully fledged build systems.

I’ve never heard of meson before. A cursory glance at the meson docs is telling me that meson is worth looking into further. Thanks!

[wirrbel]

Meson is likeable and with ninja has a great user experience. I do think it is much easier to understand than cmake (and I have some years of cmake usage under my belt(

[Shorel]

Before CMake the "proper" thing were ./configure and ./automake scripts which are an atrocity from any point of view.

More than "proper", or simply "nice looking syntax" the thing I like from CMake is that a single file makes my project compile in several versions of Linux and Windows using a variety of compilers.

Any suitable replacement system should also do this.

[tom_]

+1,000. CMake may be bad in many respects, and a bit unhelpful in others, but it makes managing multi-platform projects pretty straightforward. There's not much more cruft than you'd expect, and there's convenient support for the standard tools for the major platform - and in exchange for that, I can forgive it quite a lot.

And it does actually seems to be improving over time, too, so over time I seem to have to forgive it less, even if still measurably more than not at all.

For single-platform projects it's less essential, but I think the PUBLIC/INTERFACE project settings stuff is still a draw, and its support for Ninja build files too.

[gnufx]

To me autotools have the great advantage that I can make projects using them work relatively easily if they need adjusting in one of the many things I build, and I can write the support for a new project easily. They're pragmatic, and I don't think deserve "atrocity" by any means. In contrast, cmake often causes me to throw up my hands. It's not my experience that cmake projects just work even on GNU/Linux when needing, say, to build shared libraries or install in a different sort of tree. I've used autotools quite painlessly over many years on assorted platforms including in GCC "Canadian cross" (cross-building a cross-compiler -- between GNU/Linux, SunOS, and MS-DOS originally). I did find a new level of horror in bazel when faced with building tensorflow for a different target, despite explicit instructions for a different release.

[Shorel]

You should write an article detailing your experience with both systems.

It should make for an interesting read.

[mianos]

There is a python one, waf, https://en.m.wikipedia.org/wiki/Waf It is awesome but not very popular. I wish it was more popular. As a python and C++ developer the build files and up so much clearer than anything else. I write and use cmake files every day and I don't like it at all.

[ur-whale]

Interesting, thanks for that.

Haven't dug into it yet to say thumbs up or down, but the fact that it uses a full-fledged generic programming language instead of a DSL is a promising start.

Here's a waf "makefile":

https://gitlab.com/ita1024/waf/blob/master/demos/c++/wscript

[slavik81]

Have you tried doing anything complex? It's been a long time since I last used Waf, but I found it very difficult to extend.

[mianos]

It has been a while but I wrote an ARM and Atmel cross build system for Arduino boards. It was hard keeping compatibility with the IDE environment but the result worked and was not half as ugly as a cmake setup.

[jabl]

Meson seems increasingly popular. Never tried it myself though.

[zeotroph]

They also went the cmake route of not trying to be the build system, but the meta buildsystem which just writes out ninjafiles, or makefiles and lots of other obscure formats in case of cmake. This is probably also the reason why cmake 'won' so far.

[codedokode]

I think they did it in order not to duplicate make's functionality. Make is useful for partial rebuilds (when you change a single file only it is recompiled). You either use make or have to implement this yourself.

[notriddle]

They did it because they didn't want to duplicate Ninja's functionality. It does partial rebuilds, it's been heavily optimized for just doing that, and it's a Google-created project that they're already using for other non-Bazel projects.

[zik]

I'm loving meson. I have around a hundred thousand lines of code building with it and it's the cleanest build system I've used yet. Much less obscure than make or cmake.

[fh973]

Bazel, the open source sibling of Google's blaze.

[danaur]

I feel like there isn't a community outside of Google that uses Bazel strongly, and therefore it has weak Community Support.

[orf]

Maybe we need a language that compiles down to CMake!

[goalieca]

Well call it autocmake!

[therein]

Love it. You start with AutoCMakeLists.m4. Yes, m4 macros are back in the game again!

Using autocmake, you build that into a CMakeLists.txt. After that now you can use cmake to generate your Makefile. Voila.

[flukus]

I'll create the root makefile that invokes AutoCMake, then CMake, then Make and then all the edge cases CMake can't handle, plus add a much more usable interface.... Take out AutoCMake and it's actually what I'm doing right now.

> Yes, m4 macros are back in the game again!

Actually, I did some codegen experiments recently and found M4 to be really nice once you get past the bad documentation and actually understand it, along with ignoring any experiences with autotools of course. Besides the general substitutions and macros, the divert/undivert primitives are simple yet this is where the real power of the language is, they easily let you write to a number of named/numbered buffers and then pull them back in where needed. The wikipedia article probably shows this off more clearly than the documentation: https://en.wikipedia.org/wiki/M4_(computer_language)

[enriquto]

> found M4 to be really nice once you get past the bad documentation

The gnu m4 manual is one of my favourite technical documents, what's wrong with it?

[slavik81]

Shake looks promising to me. It has a Haskell front-end, and clearly has had a lot of thought put into it. That said, I have never tried it.

Despite CMake's attrocious syntax, the underlying compilation model has always worked more or less as I expected. I can't say that about most of the alternatives I have tried. I was frequently left confused and frustrated by my build systems until I found CMake.

[Langdal]

SCons is a build system for C and C++ (and some other languages) that is configured in Python. I haven't tried it much though.

[twic]

I've been recommended Boost.Build, aka b2, the build system Boost uses to build itself, but also usable for any other project:

https://boostorg.github.io/build/manual/develop/

[LVB]

Beware! At a previous job, Boost Build was easily one of the most unpopular aspects of the tech stack. It had 5% of people evangelizing it, and they were also the only ones who “got” the complicated Jam file arrangement. The rest of us couldn’t stand it. Just way too abstruse IMHO.

[slavik81]

I used Boost Build for years, but I never figured out how to do anything but copy/paste our existing build files. I found scraps of documentation on Jam here and there, but it never made much sense when I looked at our code. I later discovered CMake and found it much, much easier to learn.

On an unrelated note, the best comment I have ever come across is related to Boost Build: https://github.com/openembedded/openembedded/blob/fabd8e6d07...

[jcelerier]

Boost.Build is so good that even Boost is moving to CMake

[rleigh]

Did they also recommend any documentation or examples? Because I've yet to find anything that comes close to the extensive CMake documentation. Heck, even GNU autotools have better docs and examples than b2.

[bendmorris]

Scons (https://scons.org/) is one alternative. The configurations (and Scons itself) are Python.

[electricslpnsld]

Scons has soooo many problems. You still can't pass in positional linker flags without completely hacking how it calls the linker. :(

[blattimwind]

Configuration-by-full-language-by-default is IME a relatively big red flag for things like this. Much rather have a limited configuration language, possibly with the option of going full bore if needed.

Case in point, qbs is much more workable. Declarative-glue-predefined-stuff-together most of the way, JavaScript capability if needed.

[rleigh]

It's awful. It's not even a build system; it's a framework to make your own custom special snowflake build system that is unique to your project and which contains 1% of the functionality you get for free with cmake.

Take a trivial problem: enabling threading in a cross-platform manner. CMake: "find_package(Threads)" Autotools: "ACX_PTHREAD" SCons: Write it yourself.

Now multiply this by every single other detail of your project. It's wheel reinvention writ large, and no one else will have a clue how to build or work on your project.

[wirrbel]

I liked scons but it is what I would consider a legacy project that I would not introduce in new software or actively switch to.

If you like scons check out meson, which feels similar I think.

[ur-whale]

Worse, if you try to leave those lines out because just seeing them at the start of every build file, the whole ball of spit an glue pesters you with warnings. Ugh.