OSDev.org

I hate build systems, I really do, and I'm sure many here share the sentiment. I mean, it's not their fault; they're doing their best, but C/C++ were simply not designed with complex build systems in mind.

So here I wanted to ask, what build systems do you use/recommend? Personally, I've tried nearly everything under the sun, but my favorites so far are:

• tup: It's very fast, which is nice though not my priority. Really what I like about this one more has to do with its variant build feature, macros, and its rule syntax.
• Meson: This is more heavy-duty than tup, but still very fast (it uses Ninja as a backend). However, what I like most about it is that it's very intuitive as far as build systems go.
• CMake: What build system list can go without mentioning this beast? It's big, very featureful, and has a weird scripting language. (Does anyone know where they came up with this language??)

I personally think that good old Make is the best. Not too complicated, can do everything I need. There is no point to complicate something that is not supposed to be complicated.

+1

Make is versatile enough to handle the Linux kernel, so it's certainly good enough for anything I write. It's simple and tried and trusted.

Make is versatile, sure, but it has many issues as well. For one, relationships between file dependencies is broken; Make can't detect that foo.c is dependent on foo.h. Tup does this by watching what files get modified by a command, while preserving Make's versatility.

jordyd wrote:Make is versatile, sure, but it has many issues as well. For one, relationships between file dependencies is broken; Make can't detect that foo.c is dependent on foo.h. Tup does this by watching what files get modified by a command, while preserving Make's versatility.

I prefer having to specify dependencies myself, as that way I can specify only those files that really matter as dependencies. The specific problem of header file dependencies can already be solved by instructing the compiler to generate dependency files, and by specifying the rest myself I can for example avoid minor libc updates on the host system causing a need to recompile my entire kernel, whereas tup's philosophy of everything opened for reading is a dependency would also pull those in.

CMake... and only CMake....

why?

1) Integration with CTest test system which in turn integrates with CDash build dashboard system...

2) invoking cmake with the GUI/TUI option allows menu of options specific to your project - this is extremely useful for helping train new internal users/programmers about what the options are and how they effect/cascade into other options

3) robust dependency management - whether you let cmake figure 'em out or specifically forcing dependencies cmake kicks butt - especially for multiple target architectures/OS's

4) sufficient language capabilities which allow writing human understandable build scripts... meaning you can look at a project which uses cmake and even if you don't really know cmake you can understand what is going on.... unlike others ( scons )

5) more than anything else... not ever having to write a freakin' makefile again AND never having to debug someone else's crappy makefile

on the cmake language:

A) everything is a function
B) simple push/pop stack machine parser where entering a new keyword function is a push - leaving a pop

C) remember - just because you write cmake code doesn't mean cmake is the engine which executes that code - many of the cmake statements you write are translated to statements for the target build system such as make or ninja - this can be confusing


cheers

jordyd wrote:Make is versatile, sure, but it has many issues as well. For one, relationships between file dependencies is broken

I've never had any problems when using auto-dependencies: http://make.mad-scientist.net/papers/ad ... eneration/

As I said, it works for the Linux kernel, which is a moderately complicated project.

I wrote a simple configure shell script to generate Makefile by taking a few options. That pretty much cover all cases I could imagine.

+1 for CMake.

Adding to what dchapiesky wrote:

CMake allows you to generate Makefiles. But it also allows you to generate Ninja files, NMake Makefiles (for command-line use with Visual Studio), it allows you to build Visual Studio solutions, for Win32 and Win64, Debug and Release, all from the same configuration you are building your Unix Makefiles from (and without configurations slowly drifting apart over time).

(This was what made me dive into CMake in the first place -- my 9-to-5 job included holding hands for five different "build setups", one for each target system, and I was so sick of it...)

You not only get CTest tests forwarded to a CDash dashboard, you also get CPack package building -- RPM, DEB, TGZ, NSIS setup.exe for both 32 and 64 bit releases etc., without doing much (if any) additional configuration work.

With MXE.cc, you get out-of-the-box cross-compiling capabilities, compiling and packaging your software for Windows from a Linux box by doing nothing more than using MXE's CMake wrapper script instead of your native cmake.

Plus, there are pre-built solutions for integrating LaTeX doc generation, Doxygen doc generation, Javadoc generation, source reformatting / beautifying, continuous and nightly builds, ...

Today the latest version of our software is built every night, for all target platforms, with one crontab'ed command per platform, using one single CMake configuration (which is 99% identical to the JAWS setup I linked above).

You can achieve many of these things with "plain" Makefiles as well. But be honest, who ever actually did that? CMake does most of these things more or less for free...

Whatever gets the jobs done , basically. Some of the projects that i worked on were so huge that a separate build cluster was sometimes required to build/test it in a reasonable time. I would mess with internals of the build system only if something is broken.
--Thomas