Re: Linux-kernel style output

[Tommie Gannert]

> Hello Tommie,
>
> * Tommie Gannert wrote on Fri, Aug 11, 2006 at 10:45:21AM CEST:
> >
> > I've been diving into Automake to try and make it less noisy. My
solution
> > is a patch which adds --enable-pretty-commands to configure. Hopefully,
the
> > standard behavior is the same as before. I haven't tested it all fully
yet,
> > just tried it against the Heimdal package, and it seemed to work.
>
> I haven't looked at the patch in detail, but I like the fact that it
> does not enlarge the resulting Makefile.in by much.  Some of the other
> proposals caused more lines in lib/am/depend2.am, which, for some
> packages, makes for noticeably increased tarballs.  So this could be
> acceptable even for developers that otherwise do not want the "pretty"
> output.
>

In depend2, there are a few lines added (essentially one echo per rule), but
what is really space-consuming are the @address@hidden AMPRETTYCMDECHO
could perhaps be shortened to AMPECHO if it's accepted into Automake.

> Another good point is that the pretty output is not enabled by default.
> This is more important that may be obvious at first:  From a developer
> standpoint, most bug reports are by rather inexperienced users that use
> the default way of compilation.  Teaching them to also first recompile
> verbosely so that they can provide the command that caused the error
> is a burden.
>

I'm on Gentoo, so I compile alot of stuff from the sources when updating the
system,
and that is basically the reason I want to clean up the build process. One
line per task is enough,
plus it's easier to spot warnings and errors.

If developers want to know the settings a user is using, the user should
send them
config.log and config.status.

> Some quick comments to the patch:
> - If you wrote m4/prettycmds.m4 from anew, its copyright years should
>   contain only 2006; otherwise, it should contain 2006 added.
>   If you want to get this accepted into GNU Automake, you will have to
>   assign your copyright to the FSF (details off-list); otherwise the
>   copyright statement in that file is obviously wrong, as you are not
>   the FSF.
> - Some other files need copyright year updates for the changes as well.
>   All of this (and much more) is explained in the HACKING file that's
>   part of the CVS tree (and files referenced therein).

Yeah, those licensing issues. ;) I'll bother with them if you find this
worthy of inclusion
in the sources. Otherwise I'll just leave it as a standalone patch.

> - For getting this accepted, it would be helpful to have a patch against
>   the CVS HEAD version (it's almost certain Alexandre won't put this in
>   branch-1-5).

I guess this is too an issue of "worthy inclusion". For a standalone patch,
it is more convenient to have it against latest stable.

> - Have you tried the test suite with the patch?  Are you willing to add
>   new tests that expose the new functionality and make sure it works
>   everywhere (and continues to work)?

No test yet. I could probably write up some tests, yes. That is probably
something I could do right now to prove my point.

> - NEWS needs an update, and it needs a ChangeLog entry.

I thought those were updated semi-automatically... Oh well, off reading
HACKING, then. :)

>
> The more you're able to do, the easier it will be to get this accepted
> into Automake-1.10.  FWIW, I'm not to decide whether or not it should be
> accepted, but given above things are addressed, I'm in favor of it, and
> willing to test it eventually and go over some details.  I think this is
> by far the nicest approach I've seen so far for it.
>

Thanks. Requesting for comments really work on-line.

Everyone seems to be manually
writing their own rules in Makefile.am now to do the pretty-printing. That
just feels
like a work-around for something that should be in Automake.

> Cheers, and thanks for your work,
> Ralf
>