Re: Linux-kernel style output

[Tommie Gannert]

*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 Makefile.am (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)

> - Makefile.in bloat
>
>  We fighted Makefile.in bloat a couple of years ago, for some
>  project where the generated Makefile.in 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 Makefile.in
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 automake.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,
Tommie