Skip to main content

Posts

Showing posts from February, 2009

Still some hair left

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.hwould become:
lib-file2.h: Makefile @cmd=…

After-shave

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: making the autotools output sane

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/shaveHopefully, 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 tool0Just li…

ADV: ADV is a Dependency Viewer

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.



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



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 us…