automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reducing verbosity of automake


From: Brendon Costa
Subject: Re: Reducing verbosity of automake
Date: Wed, 26 Apr 2006 08:31:05 +1000
User-agent: Thunderbird 1.5.0.2 (Windows/20060308)

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

> I'm afraid that I misinterpreted what the original poster wanted to be
> a way of tidying output on a single development system, and not for all
> variations of platforms where the build process would be run. The filter
> would be a quick way of scratching his itch now, without having to wait
> for a fully general system to be implemented in the autotools.
> 
> And Yes! if required on all build platforms such a filter would indeed
> be The Ultimate Big Fat Smart Filter.
> 
> As it stands the autotools are already big fat smart filters, so maybe
> it's not as much effort to implement a completely general solution that
> would apply across platforms as it would appear at first sight.
> 
> Sorry for the confusion.

Yes the proposal is to produce a general solution that will work on all
platforms. Sorry i was not overly clear in my proposal before, i just
jumped straight into how i would achieve my goals and did not elaborate
on what the goals were.

To clarify "The Big Fat Smart Filter" i will describe the filter script
below.

The filter script would be extremely simple but could be customized on a
per project basis if their requirements were more complex.

My intent is that while running make on a project all stdout from the
operations being performed are hidden from the users (So the default
script will just pipe that to /dev/null or if the project desires, it
could go to a file and later be displayed if an error occurred) and also
the command lines used to perform operations would be hidden from the
users (Unless the operation fails). The user will however see all
warnings and errors (Unless a particular project wishes to customize the
script to hide them as well which i would not recommend, but hey it can
be done). A typical example of the filter script proposed would look like:


#! /bin/sh
#
DESCRIPTION=$1
COMMAND=$2
shift
shift

echo $DESCRIPTION
$COMMAND $* > /dev/null
RESULT=$?

if test $RESULT -ne 0; then
   echo "" 1>&2
   echo "\t$COMMAND $*" 1>&2
fi

exit $RESULT


I am still tossing up if it would be good to separate the description
argument into two arguments instead of one. 1 - The operation summary,
and 2 - The Target name.

The operation summary would look like one of: "C++", "Link", "Ar",
"Ranlib", "Install"

The target, which may be something like: "src/apps/main.o" or
"src/apps/test" or "/usr/local/lib/libblah.so"

The advantage of separating out the description into these two parts, is
that it would make it easier to customize a filter script to filter
differently based on the type of operation being performed. It also
allows the project developers to easily customize the way the
description would look.

An example of compiling using this system would look like:

make -s

C++: src/libs/Base.o
Link: src/libs/libBase.la
C++: src/apps/main.o
Link: src/apps/test


Anyhow, I hope that clarifies my proposal a little bit more.

Brendon.



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

iD8DBQFETqMpLSWCuZeiyS0RAjZCAKCbny8CGIkLnMKRC2CAiUNRhU7CtgCfUD6n
T5qbHOsjFcgOrMKuUPn+tlc=
=ZOsW
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]