First, there is ninja-build. It’s a workhorse, roughly comparable to make. It isn’t really designed to be used standalone though. Typically the lowlevel ninja build files are generated by some highlevel build tool, similar to how Makefiles are generated by autotools.
Second, there is meson, a build tool which (on unix) by default uses ninja as backend. meson appears to become pretty popular.
So, lets have a closer look at it. I’m working on drminfo right now, a tool to dump information about drm devices, which also comes with a simple test tool, rendering a test image to the display. It is pretty small, doesn’t even use autotools, perfect for trying out something new. Also nice for this post as the build files are pretty small.
So, here is the Makefile:
CC ?= gcc CFLAGS ?= -Os -g -std=c99 CFLAGS += -Wall TARGETS := drminfo drmtest gtktest drminfo : CFLAGS += $(shell pkg-config --cflags libdrm cairo pixman-1) drminfo : LDLIBS += $(shell pkg-config --libs libdrm cairo pixman-1) drmtest : CFLAGS += $(shell pkg-config --cflags libdrm gbm epoxy cairo cairo-gl pixman-1) drmtest : LDLIBS += $(shell pkg-config --libs libdrm gbm epoxy cairo cairo-gl pixman-1) drmtest : LDLIBS += -ljpeg gtktest : CFLAGS += $(shell pkg-config --cflags gtk+-3.0 cairo pixman-1) gtktest : LDLIBS += $(shell pkg-config --libs gtk+-3.0 cairo pixman-1) gtktest : LDLIBS += -ljpeg all: $(TARGETS) clean: rm -f $(TARGETS) rm -f *~ *.o drminfo: drminfo.o drmtools.o drmtest: drmtest.o drmtools.o render.o image.o gtktest: gtktest.o render.o image.o
Thanks to pkg-config there is no need to use autotools just to figure the cflags and libraries needed, and the Makefile is short and easy to read. The only thing here you might not be familiar with are target specific variables.
Now, compare with the meson.build file:
project('drminfo', 'c') # pkg-config deps libdrm_dep = dependency('libdrm') gbm_dep = dependency('gbm') epoxy_dep = dependency('epoxy') cairo_dep = dependency('cairo') cairo_gl_dep = dependency('cairo-gl') pixman_dep = dependency('pixman-1') gtk3_dep = dependency('gtk+-3.0') # libjpeg dep jpeg_dep = declare_dependency(link_args : '-ljpeg') drminfo_srcs = [ 'drminfo.c', 'drmtools.c' ] drmtest_srcs = [ 'drmtest.c', 'drmtools.c', 'render.c', 'image.c' ] gtktest_srcs = [ 'gtktest.c', 'render.c', 'image.c' ] drminfo_deps = [ libdrm_dep, cairo_dep, pixman_dep ] drmtest_deps = [ libdrm_dep, gbm_dep, epoxy_dep, cairo_dep, cairo_gl_dep, pixman_dep, jpeg_dep ] gtktest_deps = [ gtk3_dep, cairo_dep, cairo_gl_dep, pixman_dep, jpeg_dep ] executable('drminfo', sources : drminfo_srcs, dependencies : drminfo_deps) executable('drmtest', sources : drmtest_srcs, dependencies : drmtest_deps) executable('gtktest', sources : gtktest_srcs, dependencies : gtktest_deps, install : false)
Pretty straight forward translation. So, what are the differences?
First, meson and ninja have built-in support a bunch of features. No need to put anything into your build files to use them, they are just there:
- Automatic header dependencies. When a header file changes all source files which include it get rebuilt.
- Automatic build system dependencies: When meson.build changes the ninja build files are updated.
- Rebuilds on command changes: When the build command line for a target changes the target is rebuilt.
Sure, you can do all that with make too, the linux kernel build system does it for example. But then your Makefiles will be a order of magnitude larger than the one shown above, because all the clever stuff is in the build files instead of the build tool.
Second meson keeps the object files strictly separated by target. The project has some source files shared by multiple executables. drmtools.c for example is used by both drminfo and drmtest. With the Makefile above it get build once. meson builds it separately for each target, with the cflags for the specific target.
Another nice feature is that ninja automatically does parallel builds. It figures the number of processors available and runs (by default) that many jobs.
Overall I’m pretty pleased, I’ll probably use meson more frequently in the future. If you want try it out too I’d suggest to start with the tutorial.