Re: Reducing verbosity of automake

[Ralf Wildenhues]

* Brendon Costa wrote on Mon, Apr 24, 2006 at 03:29:34PM CEST:
>
> I can imagine that a makefile only based solution would add a lot of
> bloat to the Makefile.in files. There is another solution, but it
> requires a script that behaves like a layer between make and any system
> command it executes.

Any? You'll be able to feel the runtime overhead.  (Note the runtime
overhead incurred by the libtool script is huge on some systems, notably
w32 ones.)

> filter_script.sh "C++ ./main.o" g++ -Wall -g ./main.cpp -o ./main.o
> OR
> filter_script.sh "Remove blah.o" rm -rf blah.o

This isn't the worst of ideas.  `depcomp', `libtool', and `compile' are
incarnations of the same pattern: wrap the thing in a script, to add
functionality.  Works reasonably but not perfectly correctness-wise,
isn't so great performance-wise.

But let's not judge prematurely: if the script can be written to have
little overhead, it may be worth it.

> Would i be able to achieve this through autoconf without having to
> modify automake at all?

Better if you modified Automake only; you could leave Autoconf alone
for this.  Sure you could think of changing all of $CC, $RM, and what
not, but that will prove much more error-prone, I think: there are third
party configure macros out there that "parse" the output of a
compilation or of a link, and it'd be very fragile to break that.
(So at least, it should be done very late in the configure script.)

> I am still not quite sure how things work yet,
> but in the jam system. The autoconf script looked for the commands for
> mkdir, rm, g++ etc and placed them in variables in a Jamconfig file.

Stuff like rm, mkdir, is often used without resorting to variables in
all autotools: some basic functionality is expected.  So you'd end up
having to track down lots of bits.  (OTOH, for non-portable stuff, like
`mkdir -p', variables may exist; for exact semantics be sure to check
the documentation.)

> > I always prefer to just use the filter available in
> > my editor: it swallows all output, shows it to me when I'd like it to do
> > so, and otherwise jumps to the first warning or error it could parse
> > from the log.  And yes, I happen to know that *both* editors have this
> > very useful feature.  ;-)
> 
> I really need to start looking at using an IDE so i can use some of this
> functionality :-)

Yes.  I recommend two: emacs and vim.  Both are immensely useful after
the initial steep learning curve.  And both have enough magic in them
to filter the warning output of many compilers out there.


If you really want to pursue this, I recommend that you start off with
Martin Waitz' patch, and make it functional.  (If you need a copy of the
mail that is unmangled by the archiver display, ping me off-list.)
Then, add tests and a ChangeLog entry, so that at least it's complete.

Note that it's still up to the Automake maintainer whether he will
accept the idea at all after that; I really don't know Alexandre's
opinion on this.

Cheers,
Ralf