Re: Reducing verbosity of automake

[Brendon Costa]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ralf Wildenhues wrote:
> [ I assume you want Cc:s to both addresses? ]

Yep. Thanks.
By the way. Thanks for the reply. I couldn't believe it was so fast :-)



> All patches I've seen add quite a bit of bloat to Makefile.in's, for
> dubious value (remember the compile rules may be output very often with
> per-target flags).

(Note with below: I have not really thought this through. It is just a
preliminary idea that may not be feasible for some unknown reason)


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.

I.e. If a command was originally something like:
g++ -Wall -g ./main.cpp -o ./main.o
OR
rm -rf blah.o

it could be replaced in the makefile with a command like:
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 nicest way of doing things, but the script could perform
all the filtering and displaying necessary. It would simply be a matter
of telling make to prefix all commands with the given script name and a
string for the operation.

The script would pipe all stdout to /dev/null and if the command
returned an error status it would display what was used. The script
would just return the same status as was returned by the program itself
after it had completed processing.


Would i be able to achieve this through autoconf without having to
modify automake at all? 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.
These variables were used by jam to execute the commands. If a similar
system is used in automake, i could just replace the contents of those
variables... I might think about it some more tomorrow morning after
some sleep.


> 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 :-)


>
> Another reason against such a patch is that, whenever a developer gets
> a bug report, then usually the actual build output is useful, but the
> abbreviated output you suggest is close to useless.
>

It would also be possible that instead of the script just piping stdout
to /dev/null it could pipe stdout to a temporary file and cat that file
to stdout/err if an error occurred along with the command line that
failed. This would give at least some more information that could be
helpful. But in the end it would be up to the developer to choose if
they wish to activate this "feature" or not. It would be up to the
developers of the particular project to choose if they wanted/needed
that level of output to debug user bug reports or not...


> Cheers,
> Ralf
>
> [1] I know libtool isn't completely silent even with that.  I wrote a
> while ago that I'd accept a patch against CVS HEAD silencing it with
> `--silent --silent', or similarly, but that I have little incentive to
> write one myself.  Did I hear somebody volunteer now?  ;-)

Not just yet. But i will keep it in mind...

Thanks,
Brendon.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFETNK+LSWCuZeiyS0RAuRDAJ9eTroUyQL9BAuElbxqs3RQW4KnSgCgx+K3
usuuZiTILnwX06+RdVfZ9xg=
=Jbwv
-----END PGP SIGNATURE-----