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