[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Linux-kernel style output

From: Tommie Gannert
Subject: Re: Linux-kernel style output
Date: Tue, 15 Aug 2006 18:58:06 +0200

*This turned out to be long and emotional, sorry about that.*

While I appreciate the effort, I'm afraid I'm not overly fond of
this approach.

Don't worry, it's free software. ;)

- Output format

 It seems people have different needs.  Last time it was
 discussed, people mostly complained about the if/then/depcomp
 wrapper Automake outputs around the compiler, and wanted to
 see a single line with the compilation command.

Yes, one line per action/rule would be preferrable.

 A source file can be compiled several times (to different
 objects) with different options.  Showing only the source file
 without showing the object being compiled is ambiguous.

Yes. Would it be better to change the output to the object instead?

However, this is a question of taste and why you run 'make'. If you run make because you want to install a stable branch of a program (source dists), then you are most certainly not interested in objects. If you are a developer running make, I assume you will want another form of output (more verbose). The Linux kernel outputs some options
too while compiling, if I remember it correctly.

My approach as a developer is that since I wrote the (or at least has the knowledge of how to read it), I don't really need to see the exact command lines. Those
are only of value to me while writing the Makefile.

What I want to see is what is going on and what _I_ should be doing as the next step, i.e.
fixing errors and warnings, or implementing new features.

 To debug some errors, people will need a simple way to show the
 command line being executed (without rerunning configure, or
 spending time inferring it from config.log).  An example is
 when you want to rerun the compilation command with -E to debug
 some preprocessing mess.  Maybe you could turn AMPRETTYECHO into
 a Makefile variable, or something along these lines.

Yes. I don't remember why I put it as an Autoconf variable. It might
have been to reduce the Makefile size. Turning it into a make variable
would be a piece of cake... It could even be that this is an option in
the configure script. (Static on/off vs. dynamic on/off)

- bloat

 We fighted bloat a couple of years ago, for some
 project where the generated was several megabytes
 large (and still is quite big).  Adding one line for each rule
 really is a lot for such a project !  I think at least Automake
 shouldn't do so my default, but only if the support macro is
 called by the user.  (It also makes sense to let the users
 decide whether they want to support this --enable-p-c switch,
 since they'd have to fix all their custom rules.)

First of all, the pretty-command stuff could be removed from
using an if-condition in the templates. This would require some more hacking
than just outputting @address@hidden for the if-statements, but it would only require changes in Something like static-if? This was my initial though,
actually, but then I found that if's were merely a nice way of writing @'s
in front of all statements...

I was trying to fight three things with this project:

1) Developers are writing their own rules now, instead of using
the ones generated by Automake. This means they forget to include
$AM_CFLAGS, forget to use $CC or $RPCGEN, and so on. I feel
this argument is enough to include it in Automake directly. After all,
the purpose of a preprocessor is to ease the work of the programmer
and to lower the probability of errors.

2) When compiling large programs with lots of Gettext, Libtool and Yacc files, the output from 'make' is really horrible. First of all, it looks bad. Source code is in my eyes beautiful. The output of the Linux make process is equally "beautiful". I put a great effort in all my coding to avoid warnings just to make the build process "clean". I'm not an artist, I'm a coder, but nevertheless, I find beauty in
what I'm doing. Perhaps that's why I'm doing it..

3) There are now several alternatives to traditional 'make'. Ant, cons, and a number of super-'make's. Once again this is about (my taste of) beauty. I find 'make' beautiful. It is so wonderfully consistent with the Unix "small programs" approach, I can't find words for it (at least not in English :). It is so simple and powerful I really want to use it. However, writing Makefiles from scratch is a pain, and should be avoided. The Makefiles are not beautiful, if you want such things as automatic dependency calculations. This is the place for a preprocessor; Automake. In short; I like to know I have the full range of 'make'
available, and I'm glad I don't have to use it all the time.

- Template maintenance

 The am files templates certainly get a bit loaded, but I'm not
 sure how this can be helped with this scheme.

I wouldn't say "loaded". It's just that you get more characters, which
probably requires more skills to read the templates.

There is another approach that could be a lot less intrusive and
IMHO more generic and useful: pipe the output of make through a
filter to format it as you wish.  (I don't think using a wrapper
for make is more difficult than passing an option to configure.)

This has two drawbacks, as I see it:

1) Running a wrapper around 'make' will make the compilation
process more difficult... Since you are used to just writing 'make'
in any source directory, you would have to install the wrapper-make
on the system before using it. This is in contrast to the Autotools
approach of requiring as little as possible of the host. (Note that this
assumes that it is the package maintainer that whishes to use
pretty-commands for her package. And indeed, it must be, since
the explicit rules of the package maintainer would otherwise be
unparseable by the wrapper.)

2) Performing ETA calculations (I have not yet decided if this is
doable using Automake, or if it requires a patched 'make'/wrapper) would
be _a lot_ harder post-make (but see the comment below). And
my goal is to have the user know for how long her coffee break could be.

To the advantage we have:

If 'make' is as verbose as usual, it is really easy to output the
command line in case of an error.

We could of course tune the am templates a bit to ease such
output processing.  For instance adding a short `$V' in front of
the interesting part of a command so that something like `make
V=": grepme &&"' may help post processing the output.  Or
something like this.  I guess other things might be needed.  But
at least it appears this wouldn't cause code duplication in the
template, would have a limited bloat overhead, and yet would
allow many style of reformatting.

I'm not sure the "many style of reformatting" is really needed. Indeed
if you ask a hundred users and a hundred developers how they would
want their build output, you will get 300 different answers. If you give
the 200 people the choice between noisy and 'quite silent', 190 will
probably settle with these two. The other ten will insist on their output
format on this mailing list (like I do ;). This is how progress is made, IMHO.

Combining such a make wrapper with an initial `make -n'
could also help you with the two goals on your roadmap!

Yes. Doing 'make -n' initially is indeed the easiest approach to
ETA calculation. However, if this approach requires a wrapper,
I'm not sure I would ever use it. When distributing my source, I
want it neat and standard. I like the feeling of knowing that all
my beloved developer collegues have to do is the standard

  ./configure && make

It is beautiful, IMHO.

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]