Damien Lespiau

Writing m4 macro is fun, it really is.

If you want to have make be a “make -s” without doing boring stuff like aliases and actually respect the default verbosity of automake >= 1.11, use this small m4 macro I wrote.

I’ve just stumbled accross a small piece of code, written one year and a half ago, that blends two 512×512 RGBA 5551 images. It was originally written for a (good!) GIS, so the piece of code blends roads with rivers (and displays the result in a GdkPixbuf). The only thing interesting is that it uses some MMX, SSE2 and rdtsc instructions. You can have a look at the code in its git repository.

After a month without anyone shouting at shave in despair or horror, it’s time to tag something to have a “stable” branch so people can rely on a stable interface (yes, it’s important even for a 100 lines macro!).

What’s the most amazing is that quite a few projects have adopted shave in the GNOME and freedesktop.org communities : Clutter, Niepce Digital, Giggle, GStreamer, GObject introspection, PulseAudio, ConnMan, Json-glib, libunique, gnote, seed, gnome-utils, libccss, xorg ? and maybe some more I’ve forgotten or I don’t even know about.

You can grab the tarball or clone the git repositoy (git clone git://git.lespiau.name/shave) and have a look at the README file.

Time to celebrate.

I’ve been asked to give more input on make V=1 Vs. --disable-shave, so here it is: once again, before shipping your package with shave enabled by default, there is something crucial to understand: make V=1 (when having configured your package with --enable-shave) is NOT equivalent to no shave at all (ie --disable-shave). This is because the shave m4 macro is setting MAKEFLAGS=-s in every single Makefile. This means that make won’t print the commands as is used to, and that the only way to print something on the screen is to echo it. It’s precisely what the shave wrappers do, they echo the CC/CXX and LIBTOOL commands when V=1. So in short custom rules and a few automake commands won’t be displayed with make V=1.

That said, it’s possible to craft a rule that would display the command with shaved enabled and make V=1. The following rule:

 lib-file2.h: Makefile
        $(SHAVE_GEN)echo "#define FOO_DEFINE 0xbabe" > lib-file2.h

would become:

 lib-file2.h: Makefile
        @cmd='echo "#define FOO_DEFINE 0xbabe" > lib-file2.h'; \
        if test x"$$V" = x1; then echo $$cmd; fi
        $(SHAVE_GEN)echo "#define FOO_DEFINE 0xbabe" > lib-file2.h

which is quite ugly, to say the least. (if you find a smarter way, please enlighten me!).

On the development side, shave is slowly becoming more mature:

• Thanks to Jan Schmidt, shave works with non GNU sed and echo that do not support -n. It now works on Solaris, hopefully on BSDs and various Unixes as well (not tested though).
• SHAVE_INIT has a new, optional, parameter which empowers the programmer to define shave’s default behaviour (when ./configure is run without shave any related option): either enable or disable. ie. SHAVE_INIT([autootols], [enable]) will instruct shave to find its wrapper scripts in the autotools directory and that running ./configure will actually enable the beast. SHAVE_INIT without parameters at all is supposed to mean that the wrapper scripts are in $top_builddir and that ./configure will not enable shave without the --enable-shave option.
• however, shave has been reported to fail miserably with scratchbox.

A few concerns have been raised by shave, namely not being able to debug build failure in an automated environment as easily as before, or users giving  useless bug reports of failed builds.

One capital thing to realize is that, even when compiling with make V=1, everything that was not echoed was not showed (MAKEFLAGS=-s).

Thus, I’ve made a few changes:

• Add CXX support (yes, that’s unrelated, but the question was raised, thanks to Tommi Komulainen for the initial patch),
• add a –enable-shave option to the configure script,
• make the Good Old Behaviour the default one,
• as a side effect, the V and Q variables are now defined in the m4 macro, please remove them from your Makefile.am files.

The rationale for the last point can be summarized as follow:

• the default behaviour is as portable as before (for non GNU make that is), which is not the case is shave is activated by default,
• you can still add –enable-shave to you autogen.sh script, bootstraping your project from a SCM will enable shave and that’s cool!
• don’t break tools that were relying on automake’s output.

Grab the latest version! (git://git.lespiau.name/shave)

updated: Automake 1.11 has been release with “silent rules” support, a feature that supersedes the hack that shave is. If you can depend on automake 1.11 please consider using its silent rules rather than shave.

updated: add some gtk-doc info

updated: CXX support thanks to Tommi Komulainen

shave

Fed up with endless screens of libtool/automake output? Fed up with having to resort to -Werror to see warnings in your code? Then shave might be for you. shave transforms the messy output of autotools into a pretty Kbuild-like one (Kbuild is the Linux build system). It’s composed of a m4 macro and 2 small shell scripts and it’s available in a git repository.

git clone git://git.lespiau.name/shave

Hopefully, in a few minutes, you should be able to see your project compile like this:

$ make
Making all in foo
Making all in internal
  CC    internal-file0.o
  LINK  libinternal.la
  CC    lib-file0.o
  CC    lib-file1.o
  LINK  libfoo.la
Making all in tools
  CC    tool0-tool0.o
  LINK  tool0

Just like Kbuild, shave supports outputting the underlying commands using:

$ make V=1

Setup

• Put the two shell scripts shave.in and shave-libtool.in in the directory of your choice (it can be at the root of your autotooled project).
• add shave and shave-libtool to AC_CONFIG_FILES
• add shave.m4 either in acinclude.m4 or your macro directory
• add a call to SHAVE_INIT just before AC_CONFIG_FILES/AC_OUTPUT. SHAVE_INIT takes one argument, the directory where shave and shave-libtool are.

custom rules

Sometimes you have custom Makefile rules, e.g. to generate a small header, run glib-mkenums or glib-genmarshal. It would be nice to output a pretty ‘GEN’ line. That’s quite easy actually, just add few (portable!) lines at the top of your Makefile.am:

V         = @
Q         = $(V:1=)
QUIET_GEN = $(Q:@=@echo '  GEN   '$@;)

and then it’s just a matter of prepending $(QUIET_GEN) to the rule creating the file:

lib-file2.h: Makefile
       $(QUIET_GEN)echo "#define FOO_DEFINE 0xbabe" > lib-file2.h

gtk-doc + shave

gtk-doc + shave + libtool 1.x (2.x is fine) is known to have a small issue, a patch is available. Meanwhile I suggest adding a few lines to your autogen.sh script.

sed -e 's#) --mode=compile#) --tag=CC --mode=compile#' gtk-doc.make > gtk-doc.temp \
        && mv gtk-doc.temp gtk-doc.make
sed -e 's#) --mode=link#) --tag=CC --mode=link#' gtk-doc.make > gtk-doc.temp \
        && mv gtk-doc.temp gtk-doc.make

dolt + shave

It’s possible to use dolt in conjunction with shave with a surprisingly small patch to dolt.

Real world example: Clutter

$ make
GEN   stamp-clutter-marshal.h
GEN   clutter-marshal.c
GEN   stamp-clutter-enum-types.h
Making all in cogl
Making all in common
CC    cogl-util.o
CC    cogl-bitmap.o
CC    cogl-bitmap-fallback.o
CC    cogl-primitives.o
CC    cogl-bitmap-pixbuf.o
CC    cogl-clip-stack.o
CC    cogl-fixed.o
CC    cogl-color.o
cogl-color.c: In function ‘cogl_set_source_color4ub’:
cogl-color.c:141: warning: implicit declaration of function ‘cogl_set_source_color’
CC    cogl-vertex-buffer.o
CC    cogl-matrix.o
CC    cogl-material.o
LINK  libclutter-cogl-common.la
[...]

Eh! now we can see a warning there!

TODO

This is a first release, shave has not been widely tested aka it may not work for you!

• test it with a wider range of automake/libtool versions
• shave won’t work without AC_CONFIG_HEADERS due to shell quoting problems
• see what can be done for make install/dist (they are prettier thanks to make -s, but we probably miss a few actions)
• there is a ‘-s’ hardcoded in MAKEFLAGS,  I have to find a way to make it more flexible

A few months ago I wrote a small script to draw a dependency graph between the object files of a library (the original idea is from Lionel Landwerlin). You’ll need an archive of your library for the tool to be able to look for the needed pieces. Let’s have a look at a sample of its output to understand what it does. I ran it against the HEAD of clutter.

A view of the clutter library

This graph was generated with the following (tred is part of graphviz to do transitive reductions on graphs):

$ adv.py clutter/.libs/libclutter-glx-0.9.a | tred | dot -Tsvg > clutter.svg

You can provide more than one library to the tool:

./adv.py ../clutter/clutter/.libs/libclutter-glx-0.9.a \
../glib-2.18.4/glib/.libs/libglib-2.0.a \
../glib-2.18.4/gobject/.libs/libgobject-2.0.a \
| tred | dot -Tsvg > clutter-glib-gobject-boxed.svg

clutter, glib and gobject

What you can do with this:

• trim down your library by removing the object files you don’t need and that are leafs in the graph. This was actually the reason behind the script and it proved useful,
• get an overview of a library,
• make part of a library optional more easily.

To make the script work you’ll need graphviz, python, ar and nm (you can provide a cross compiler prefix with –cross-prefix).

Interested? clone it! (or look at the code)

$ git clone git://git.lespiau.name/misc/adv