Re: Reducing verbosity of automake
Hi Sean, * Christopher Sean Morrison wrote on Sat, May 20, 2006 at 07:26:39PM CEST: Usually, the problem from a purely practical standpoint is that the error is rarely at the very end, it's somewhere probably in the last 50-200 lines or so of the output depending on the situation. So they either send me the entire massive log (because all things being equal, that's the safest thing for me to instruct of them) or they send me only the very last 2-3 lines that say Error, which is almost always useless. So why don't you instruct them to send the complete output of make -s LIBTOOLFLAGS=--silent || make which should at least increase the signal to noise ratio somewhat. Cheers, Ralf
Re: Reducing verbosity of automake
Howdy Ralf, I so sometimes instruct them to do that, usually when helping people interactively, and I get mixed results. Some get it right and I get a condensed log, some actually don't and I end up spending even more time trying to figure out what went wrong on their end (typos, misunderstandings, additional questions, etc). You can chaulk that up to dumb users but that's somewhat unfair in my opinion as there is additional complexity, albeit minimal, and hence potential for even careless mistakes. Either way, it does happen from time to time and when it does, it ends up being more of a burden on both my end and their end. Personally, I'd rather the burden be on my end while still giving as much of a clean build experience to my external compiling users as possible (within the reason and limitations of the build system tools, of course). Moreover, even when there is nothing at all wrong, I even appreciate and like the simple one-line build progress status output that you don't get during the two-phase silent make. Also, users don't have to stop two makes if they want to abort the build -- minor detail, but annoying nonetheless (sure I can bootstrap a build script and abort that instead). I'm not really complaining about the massive logs even if it might sound like it. It is the safest, simplest, and most informative route given the current build system capabilities. Just having seen the rather neat and organized output of different systems makes one yearn for improvement. Sure my commodity Toyota build system might get me there and do a fine job at it reliably, but I can certainly appreciate and want the better German engineering features in a BMW build system too. Turning the air conditioner off and rolling down the windows in the Toyota might make problems easier to diagnose, but people simply aren't used to that unless they're a mechanic regardless of what the owner's manual might dictate. If a nice heads up display that neatly tells them what the problem is regardless of their usage or situation can be provided like found on the BMW by a AM_CC_FILTER or somesuch, even better. ;-) Cheers! Sean On Thursday, May 25, 2006, at 01:59AM, Ralf Wildenhues [EMAIL PROTECTED] wrote: Hi Sean, * Christopher Sean Morrison wrote on Sat, May 20, 2006 at 07:26:39PM CEST: Usually, the problem from a purely practical standpoint is that the error is rarely at the very end, it's somewhere probably in the last 50-200 lines or so of the output depending on the situation. So they either send me the entire massive log (because all things being equal, that's the safest thing for me to instruct of them) or they send me only the very last 2-3 lines that say Error, which is almost always useless. So why don't you instruct them to send the complete output of make -s LIBTOOLFLAGS=--silent || make which should at least increase the signal to noise ratio somewhat. Cheers, Ralf
Re: Reducing verbosity of automake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for that response. I agree fully with your evaluation of the problem at hand with overly verbose log files. I was unaware of that application you mentioned, I may have a look for it later. Thanks again. Due to various reasons, I have decided to continue using jam instead of moving to automake. Though I still think that this filtering modification would be extremely useful for a large number of projects that use automake. I have committed myself to using jam now, so there is little likelihood that I will now be involved in working on such a patch. I still think it is a patch that would benefit the automake community and as such I would encourage anyone that has the time and means to develop such a patch to give it a go, but I guess it also depends on whether it would be accepted into the automake source tree. That was also one reason that I decided to not look further into this patch. I.e. I was not able to afford the time required to learn automake and develop a patch and have the chance that it may not be accepted. In addition I am familiar with the usage of jam, with the only disadvantage of using jam in my situation being that it is not as accessible on all platforms (I.e. make is installed on practically every platform, but jam is not). I am thinking of doing things like the boost libraries and distributing jam with my projects. Thanks, Brendon. For what it's worth, I think that the basic idea is a good one. The fundamental idea of basically just giving ticking progress bar style status output when everything is fine is useful both for internal and external developers. Most of the projects I deal with are massive with thousands of files, so I generally have the opposite problem of users providing the gargantuan logs when all I needed to see was somewhere near the end of the log (due to the verbosity of make, compiler, linker, etc). Usually, the problem from a purely practical standpoint is that the error is rarely at the very end, it's somewhere probably in the last 50-200 lines or so of the output depending on the situation. So they either send me the entire massive log (because all things being equal, that's the safest thing for me to instruct of them) or they send me only the very last 2-3 lines that say Error, which is almost always useless. Here's an example from a recent user report: (cd .libs rm -f libfoo.la ln -s ../libfoo.la libfoo.la) make[4]: *** [libfoo1.2.la] Error 130 make[3]: *** [all-recursive] Error 130 make[2]: *** [all-recursive] Error 130 make[1]: *** [all-recursive] Error 130 make: *** [all-recursive] Error 130 The real error is nowhere to be found so they then resort to sending me the several MB full log where I jump to the somewhere near the end and the real error is isolated. 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. [snip...] I actually ran across an application that did something almost exactly as you suggest. I was rather excited at first as the output from this autotools-using project was incredibly simplified. Upon examination, the developer had achieved this end by writing an application that configure built and through a processing step, it modified the resulting Makefiles to invoke their wrapper/filter application in leu of CC and LD, etc for just about everything that make would have otherwise invoked. Their binary filter application was instead invoked by make as one might expect (with make running silent), suppressing whatever build step was occurring, and only reporting errors/warnings (though, displaying the compile/link lines if there was an error). This resulted in the entire build process just ticking away a single line to give you some sense of the progress. On the surface, it was beautifully elegant and actually rather eye-candy pleasing (it surprised me at first, which led me to investigate). Underneath however, it unfortunately made me shudder as it was tied to recognizing compiler output (requiring additional effort to use a non-gcc compiler through the wrapper), involved trusting/recognizing error codes (several compilers dump serious warnings/errors without an error code), and used a rather hackish means to modify the Makefiles to correctly inject itself as a filter. The name of this project that did this escapes me at the moment. Somewhere in the BSD ports tree... :-) I would think that an automake or autoconf solution would be possible/desireable and I would be one to chime in as an interested developer for several projects. If only as a means to simplify the injection of filters. Example, something like AM_CC_FILTER would replace all instances of CC blah blah with FILTER CC blah blah, so that users could write a script as
Re: Reducing verbosity of automake
Date: Mon, 24 Apr 2006 23:29:34 +1000 From: Brendon Costa [EMAIL PROTECTED] Subject: Re: Reducing verbosity of automake To: automake@gnu.org, Brendon Costa [EMAIL PROTECTED] 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) Brendon, For what it's worth, I think that the basic idea is a good one. The fundamental idea of basically just giving ticking progress bar style status output when everything is fine is useful both for internal and external developers. Most of the projects I deal with are massive with thousands of files, so I generally have the opposite problem of users providing the gargantuan logs when all I needed to see was somewhere near the end of the log (due to the verbosity of make, compiler, linker, etc). Usually, the problem from a purely practical standpoint is that the error is rarely at the very end, it's somewhere probably in the last 50-200 lines or so of the output depending on the situation. So they either send me the entire massive log (because all things being equal, that's the safest thing for me to instruct of them) or they send me only the very last 2-3 lines that say Error, which is almost always useless. Here's an example from a recent user report: (cd .libs rm -f libfoo.la ln -s ../libfoo.la libfoo.la) make[4]: *** [libfoo1.2.la] Error 130 make[3]: *** [all-recursive] Error 130 make[2]: *** [all-recursive] Error 130 make[1]: *** [all-recursive] Error 130 make: *** [all-recursive] Error 130 The real error is nowhere to be found so they then resort to sending me the several MB full log where I jump to the somewhere near the end and the real error is isolated. 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. [snip...] I actually ran across an application that did something almost exactly as you suggest. I was rather excited at first as the output from this autotools-using project was incredibly simplified. Upon examination, the developer had achieved this end by writing an application that configure built and through a processing step, it modified the resulting Makefiles to invoke their wrapper/filter application in leu of CC and LD, etc for just about everything that make would have otherwise invoked. Their binary filter application was instead invoked by make as one might expect (with make running silent), suppressing whatever build step was occurring, and only reporting errors/warnings (though, displaying the compile/link lines if there was an error). This resulted in the entire build process just ticking away a single line to give you some sense of the progress. On the surface, it was beautifully elegant and actually rather eye- candy pleasing (it surprised me at first, which led me to investigate). Underneath however, it unfortunately made me shudder as it was tied to recognizing compiler output (requiring additional effort to use a non-gcc compiler through the wrapper), involved trusting/recognizing error codes (several compilers dump serious warnings/errors without an error code), and used a rather hackish means to modify the Makefiles to correctly inject itself as a filter. The name of this project that did this escapes me at the moment. Somewhere in the BSD ports tree... :-) I would think that an automake or autoconf solution would be possible/ desireable and I would be one to chime in as an interested developer for several projects. If only as a means to simplify the injection of filters. Example, something like AM_CC_FILTER would replace all instances of CC blah blah with FILTER CC blah blah, so that users could write a script as you suggested or an entire program as the application I spoke of wrote, and do so with relative trivial ease. It would then of course be in the filter's domain to echo the arguments or not, optionally even utilizing make's silent option or environment variables to decide. The filter could compile silently, write out action transcripts, reformat output for different purposes, inject global pre/post-processing phases, etc. An interesting and useful idea, in my humble opinion. Cheers! Sean
Re: Reducing verbosity of automake
* 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
Re: Reducing verbosity of automake
Brendon Costa [EMAIL PROTECTED] wrote: ... When compiling a project using: autoconf/automake/libtool, there is just too much data being output to the screen when i run the make command. In the jam system i am porting over if I was to issue the jam command, it would print messages like: C++ ./out/netbsd/debug/src/libs/System/unix/UnixUtils.o C++ ./out/netbsd/debug/src/libs/System/unix/Utils.o Archive ./out/netbsd/debug/src/libs/libADS_System.a Ranlib ./out/netbsd/debug/src/libs/libADS_System.a MkDir1 ./out/netbsd/debug/src/apps/boost_pointers C++ ./out/netbsd/debug/src/apps/boost_pointers/main.o LinkApplication boost_pointers ... It might be a nice feature to add this to the autotools, but is it really necessary? Why not follow the unix philosophy and write your own filter (using sed, python, perl, whatever) that reduces the verbose lines you don't want into something more managable? Then simply run make | filter I realise that this isn't a central solution that would then be available to everyone at a single stroke, but it is available to you now, and you can customise it however you want. Cheers D.
Re: Reducing verbosity of automake
Hello all, On Tue, Apr 25, 2006 at 09:13:01AM +0200, Duncan Gibson wrote: C++ ./out/netbsd/debug/src/libs/System/unix/UnixUtils.o C++ ./out/netbsd/debug/src/libs/System/unix/Utils.o Archive ./out/netbsd/debug/src/libs/libADS_System.a Ranlib ./out/netbsd/debug/src/libs/libADS_System.a MkDir1 ./out/netbsd/debug/src/apps/boost_pointers C++ ./out/netbsd/debug/src/apps/boost_pointers/main.o LinkApplication boost_pointers It might be a nice feature to add this to the autotools, but is it really necessary? Why not follow the unix philosophy and write your own filter (using sed, python, perl, whatever) that reduces the verbose lines you don't want into something more managable? You have to maintain it when any of that tools change their output format. If I were to develop such a thing, I'd rather try to tailor individual tools to suit my needs and consider maintaining three patches for autoconf, automake, and libtool. IMHO, it's The Ultimate Big Fat Smart Filter for All Known Output Types that doesn't fit the Unix tradition. I don't think this is just nice to have. If you have a large package, you want to get minimum of information possible, still getting the information about the warnings and errors, and getting the single relevant command line quickly and automatically. Autotools work great for the free software development, which is almost an ideal world -- all developers are experts, maintain a few number of packages, maintain meaning constantly improve. A simple example: many free software packages tend to have zero warnings. In the real world, developers have different areas of specialization, tight deadlines, and different priorities; fixing warnings in an imported piece of code after a compiler upgrade may not be high on that list. The question is whether autotools can serve these people better; my opinion is yes. This reminds me about the Linux kernel: cvs did work, but it didn't scale; thus the motivation for BitKeeper and git. Make does work, but look at Kbuild: it has the proposed feature; tell me why. Please note that the Linux kernel is a free software project, but no one in the real world is willing to make CFLAGS=-Werror /dev/null make to fix warnings in his own code. I personally use emacs, which does have those advanced filters, and it's still very inconvenient to work on a file compiled toward the end of the build, due to a very long output; in fact, many of my users are not aware of warnings because the information is get lost in the noise -- and hey, wasn't outputting sparingly one of the Unix traditions ;) ? I could give some more examples why this and that tool combination solution didn't work for me, but I'd like to keep my point short in this posting. I would welcome every effort spent for that feature, and would like to test it if there is anything to. With kind regards, Baurzhan.
Re: Reducing verbosity of automake
I wrote: It might be a nice feature to add this to the autotools, but is it really necessary? Why not follow the unix philosophy and write your own filter (using sed, python, perl, whatever) that reduces the verbose lines you don't want into something more managable? [EMAIL PROTECTED] replied: You have to maintain it when any of that tools change their output format. If I were to develop such a thing, I'd rather try to tailor individual tools to suit my needs and consider maintaining three patches for autoconf, automake, and libtool. IMHO, it's The Ultimate Big Fat Smart Filter for All Known Output Types that doesn't fit the Unix tradition. 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. Cheers Duncan
Re: Reducing verbosity of automake
-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 12 echo \t$COMMAND $* 12 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-
Re: Reducing verbosity of automake
Brendon Costa wrote:
Seems pretty reasonable to me, but I'd suggest a little tweak:
#! /bin/sh
#
DESCRIPTION=$1
COMMAND=$2
shift
shift
echo $DESCRIPTION
$COMMAND $* /dev/null
---
output=`$COMMAND ${1+$@}`
RESULT=$?
if test $RESULT -ne 0; then
exec 12
echo Command failure:
echo \t$COMMAND $*
echo $output
fi
exit $RESULT
Reducing verbosity of automake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi All, I have just recently started using automake and have been attempting to port over a system that uses jam to now use automake. While doing this i have come across a feature i seem unable to find within automake. I have searched the mailing lists and the web for some information and noticed that this issue has come up a few times, but I have been unable to find a solution yet. When compiling a project using: autoconf/automake/libtool, there is just too much data being output to the screen when i run the make command. In the jam system i am porting over if I was to issue the jam command, it would print messages like: C++ ./out/netbsd/debug/src/libs/System/unix/UnixUtils.o C++ ./out/netbsd/debug/src/libs/System/unix/Utils.o Archive ./out/netbsd/debug/src/libs/libADS_System.a Ranlib ./out/netbsd/debug/src/libs/libADS_System.a MkDir1 ./out/netbsd/debug/src/apps/boost_pointers C++ ./out/netbsd/debug/src/apps/boost_pointers/main.o LinkApplication boost_pointers If one of the commands being executed sends anything to stderr like warnings or errors the user will see them, but if all is working fine, then you see just this clean looking summary of what is occurring in order to build the system. I.e. the stdout from each command is being piped to /dev/null but errors come through as normal. The other thing it does is that if a command being executed returns an error (i.e. failed to compile or link etc) then the jam system will display the command line used. For example (Note edited the error message and g++ command a little to make it more readable for this post): C++ ./out/netbsd/debug/src/apps/test_inetaddress/main.o main.cpp: In function `void RunServer(int)': main.cpp:14: error: `x' undeclared (first use this function) main.cpp:14: error: (Each undeclared identifier is reported only once for each function it appears in.) g++ -c -o main.o -I/home/bcosta/cvs/ADS/System/. -I. -Wall -ansi - -pedantic -Wno-long-long main.cpp I have been trying to find an option in automake to enable a this sort of reporting and have not been successful. Some things have helped to reduce the amount of output like passing the -s flag to make, and sending the --silent flag to libtool, however they still do not produce a very clean looking summary of the build progress that makes it easy to spot warnings/errors. Is there currently any feature like this available in automake? If not how difficult would it be for someone who does not have much experience yet with automake to add this sort of feature? I also found one message in the mailing list archives that provided a patch which achieved something like this, but i was unable to successfully build the patched autoconf (i may look into this more later if i decide to go down this path). A link to that message can be found at: http://lists.gnu.org/archive/html/automake/2005-08/msg00030.html Thanks, Brendon. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) iD8DBQFETMJ/LSWCuZeiyS0RAia4AJ956/nrA6xEW9jI7jE2Cr0HuRZ0ugCbB9UR oJrueH2SD/QwjaTrjKaNqvg= =7+EV -END PGP SIGNATURE-
Re: Reducing verbosity of automake
[ I assume you want Cc:s to both addresses? ] Hi Brendon, * Brendon Costa wrote on Mon, Apr 24, 2006 at 02:20:15PM CEST: When compiling a project using: autoconf/automake/libtool, there is just too much data being output to the screen when i run the make command. make -s or even make -s LIBTOOLFLAGS=--silent helps.[1] If one of the commands being executed sends anything to stderr like warnings or errors the user will see them, but if all is working fine, then you see just this clean looking summary of what is occurring in order to build the system. I.e. the stdout from each command is being piped to /dev/null but errors come through as normal. Ah, even simpler: make /dev/null The other thing it does is that if a command being executed returns an error (i.e. failed to compile or link etc) then the jam system will display the command line used. Ah, for this, do make -s || make Is there currently any feature like this available in automake? Just what I noted above. (I know this isn't /quite/ what you want.) If not how difficult would it be for someone who does not have much experience yet with automake to add this sort of feature? 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). 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. ;-) 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. 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? ;-)
Re: Reducing verbosity of automake
-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-
Re: Reducing verbosity of automake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well i had a small look at the proposal i made last night, and it seems that it is not possible to achieve what i was saying entirely from autoconf by setting the command variables to be prefixed with the script command. Reasons include: 1) It would be extremely difficult to obtain the target for the operation, i.e. for the command CXX to give an output of the form: C++ ./blah/main.cpp it would be difficult to find the filename. It may be possible with sed, but that is just getting ugly. 2) It does not work nicely with libtool. When using libtool there will be multiple occurrences of executing this script for a single command. I.e. may be executing something like: command_filter.sh C++: file.blah libtool --tag=CXX --mode=compile command_filter.sh g++ So to achieve the functionality i desire i will need to modify automake. I had a brief look at how i could do this manually for a small test case. I ran configure for a small project i have created, and manually edited the resulting Makefiles in a few places. I managed to achieve the results i was after. If i go ahead and try to update autoconf/automake in order to add this as an optional feature that can be enabled by adding a specific macro to the configure.ac file, will it be accepted? My proposal is as follows: A developer can choose to add this optional functionality of displaying clean output to a projects build system. This would be achieved by adding a macro to the configure.ac file that looks something like: AM_CLEAN_OUTPUT([yes]) If this macro is NOT included in the configure.ac file, then all Makefile.in files will remain exactly as they are now (I am assuming that automake parses the configure.ac file as well as the Makefile.am files but could be wrong on this). If however it is provided in the configure.ac file (With a value of yes or no) then the Makefile.in files will be modified to prefix every command with something like: $AM_COMMAND_FILTER C++: [EMAIL PROTECTED] $(CC) The autoconf macro would create a subst variable for AM_COMMAND_FILTER that includes the full path to a script. The script executed can be one of: filter_command.sh: Runs a command with given arguments piping the stdout of the command to /dev/null (May think about piping to a temporary file later). Before it executes the command the script will display a description message which is a simple summary of the command being executed like: C++: some/path/file.cpp. If the command returns with an error status, then the script will display the command line that was executed. The script will then exit with the status that the command exited with. execute_command.sh: Runs a command with given arguments. It does not redirect stdout or stderr anywhere but just executes the command. When the command exits then the script will exit with the status that the command exited with. The purpose of this script is to provide a single interface for use in the Makefiles. Both the above scripts have the same usage: ./filter_command.sh description command args... The macro described above AM_CLEAN_OUTPUT([yes]) would allow the user to override the clean output by specifying a --with-clean-am-output or - --without-clean-am-output. The configure script would then export the AM_COMMAND_FILTER variable with the full path to filter_command.sh if the clean output is enabled, or to the execute_command.sh script if it is disabled. These two scripts would be located in the directory specified by the AC_CONFIG_AUX_DIR macro. Thinking about the size overhead for the Makefile.in file that this would create, it would require an extra variable exported for each Makefile.in that contains the full path to the script to execute. In addition to this, each command like executing the CXX command, or executing libtool etc would have a prefix. There will be no additional targets etc, but each target will be a little larger but i think that the cost would be negligible and if it was a problem, then the developer does not need to use this feature. One other thing i noticed is that doing this still requires that i execute make -s That is not really a problem, but does anyone know of a way of making it so that the -s flag does not need to be specified if i use the above approach. If anyone has comments or suggestions (Remember that i have no experience yet with developing automake) i would greatly appreciate it. Thanks, Brendon. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) iD8DBQFETXZELSWCuZeiyS0RAoobAJ9vsRISvC8kW4kO7vl2J4r/NxM9BQCfaNnR bvYKgTcnICGQG+Zll+dZSgk= =r91c -END PGP SIGNATURE-
