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.
And of course the wizened software engineer in me has to be restrained: "Oh hey, I can make a better build system than that..."
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 . . . . :-)
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.
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!
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.
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.
It should make for an interesting read.
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
Using autocmake, you build that into a CMakeLists.txt. After that now you can use cmake to generate your Makefile. Voila.
> 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)
The gnu m4 manual is one of my favourite technical documents, what's wrong with it?
Take divert for instance like a mentioned above, it's one of the foundations that make m4 good but it's not mentioned until chapter 10 and even then the examples are hard to follow and not particularly good, they could have gone with something more real world:
define(INDEX, 1)
define(BODY, 2)
define(ADD_CHAPTER, heading, text
divert(INDEX)
heading
divert(BODY)
heading
text
)
#guts of the generation go here
ADDCHAPTER('one', 'paragraph one')
ADDCHAPTER('two', 'paragraph two')
undivert(INDEX)
unidvert(BODY)
The syntax there isn't correct, but I think an example like that shows off how and why you'd use this feature more than the examples in the documentation.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.
On an unrelated note, the best comment I have ever come across is related to Boost Build: https://github.com/openembedded/openembedded/blob/fabd8e6d07...
Case in point, qbs is much more workable. Declarative-glue-predefined-stuff-together most of the way, JavaScript capability if needed.
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.
If you like scons check out meson, which feels similar I think.