[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Linux-kernel style output
Re: Linux-kernel style output
Fri, 11 Aug 2006 11:51:32 +0200
> 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
> > is a patch which adds --enable-pretty-commands to configure. Hopefully,
> > standard behavior is the same as before. I haven't tested it all fully
> > 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"
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
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
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
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
like a work-around for something that should be in Automake.
> Cheers, and thanks for your work,
Re: Linux-kernel style output, Alexandre Duret-Lutz, 2006/08/15