Re: CVS version is not less verbose

[Bob Rossi]

On Tue, Apr 22, 2003 at 09:34:36PM +0200, Alexandre Duret-Lutz wrote:
> >>> "William" == William S Fulton <address@hidden> writes:
> 
>  William> I see that the CVS version of Automake has been modified to make it
>  William> less verbose for FASTDEP dependencies. I feel that the 
> implementation
>  William> is a worse solution compared with the current release as it does not
>  William> honour 'make -s'; the compiler command line still appears on the
>  William> screen because it uses echo, making it rather verbose when it is
>  William> expected to be silent.
> 
>  William> I frequenctly use 'make -s' otherwise warnings are easily missed as
>  William> they appear amongst all the compilation commands. For developers
>  William> compiling the same files over and over the compilation command is
>  William> unimportant obscuring noise compared to the compiler's output.
> 
>  William> I suggest undoing this change or finding an alternative. I'd suggest
>  William> one, but I can't see how it can be done. Sorry.
> 
>  William> William
> 
> This change was requested by four people so far.  I've lost the
> pointer to the first request (which, I think, wasn't answered).
> Here are the links to the other requests or discussions.
> 
> http://sources.redhat.com/ml/automake/2002-10/msg00071.html
> 
> (This is one thread, but Karl's mailer doesn't output References)
> http://sources.redhat.com/ml/bug-automake/2002/msg02057.html
> http://sources.redhat.com/ml/bug-automake/2002/msg02073.html
> http://sources.redhat.com/ml/bug-automake/2002/msg02087.html
> 
> http://mail.gnu.org/archive/html/automake-patches/2003-03/msg00016.html
> 
> http://sources.redhat.com/ml/automake/2003-03/msg00077.html
> 
> Karl and William seem to have agreed that printing the
> compilation command on one line would be fine.  Since they also
> agreed that their private discussion should be public, I've
> attached their last mails so that other can comment.
> 
> As far as I am concerned, I don't care about either way.  The
> "with so much output I will miss warnings" argument cannot be
> mine because
>   (1) I use emacs to compile, and it catches warnings for me.
>   (2) I compile with -Werror.
> 
> Other things to consider:
> 
>  - libtool will echo the command it runs
> 
>  - the FASTDEP rules can be disabled by forcing the "gcc" dependency
>    tracking mode
>       ./configure am_cv_CC_dependencies_compiler_type=gcc
>    (replace CC by CXX for C++) 
> 
> -- 
> Alexandre Duret-Lutz

> Subject: Topics
> 
> Topics:
>    Re: CVS version is not less verbose
>    Re: CVS version is not less verbose
>    Re: CVS version is not less verbose
> 

> Date: Mon, 21 Apr 2003 15:07:29 +0100
> From: William S Fulton <address@hidden>
> To: Karl Berry <address@hidden>
> CC: address@hidden
> Subject: Re: CVS version is not less verbose
> 
> Karl Berry wrote:
> > Hi William, Alexandre,
> > 
> >     worse solution compared with the current release as it does not honour 
> >     'make -s'
> > 
> > I was the one who pushed for this change.  I had two reasons:
> > 
> > 1) make install is already done that way, with a fake echo showing what
> >    the "normal" command is.  I guess you don't run make -s install?
> > 
> > 2) all the dependency stuff is meaningless noise in 99% of compilations,
> >    and makes each file take five lines of output on the screen instead
> >    of one.  This is simply annoying, forcing lots of scrolling, etc.  I
> >    generally use next-error in Emacs, but still, sometimes I need to
> >    look through the output, and all the dependency junk makes it hard.
> > 
> > I understand the unfortunate side effect with -s, though.  (I infer that
> > was your solution to the too-much-output problem. :)
> > 
> Indeed it is what I use to overcome the exuberant automake output. It is also 
> a great 
> approach with handcrafted makefiles. It enables a reliable method to spotting 
> errors 
> because anything appearing after running 'make -s' indicates a compilation 
> problem.
> 
> > How about make >/dev/null?  Won't warnings and such show up on stderr?
> > 
> Some compilers output to stdout, not necessarily correct but it happens. I'm 
> not sure that
> Automake should be producing make files that require work arounds in order to 
> use make as
> designed. I don't know what the exact design goals of Automake are, but 
> suspect that it is
> to produce make files that work with the handful of make flags, like -j and 
> hopefully -s.
> Perhaps an Automake developer can clarify this?
> 
> 'make -s install' is a once in a blue moon operation unlike normal 
> compilation so am
> personally not bothered about this one, but perhaps this strictly ought to be 
> fixed?
> 
> > The only other suggestion I can think of is to make it an option, so
> > that we can each have our preferred methods.  However, that requires
> > more work from Alexandre.  I don't know how much.
> > 
> > 
> I also don't like all the noise that the dependency info generates, but see 
> it as an
> unfortunate side effect for gaining dependency tracking. I feel that the CVS 
> solution 
> isn't a complete solution as it still shows a lot of the compilation junk 
> including the 
> dependency flags. Everyone's project is different, but here is a real world 
> example I work on:
> 
> Automake CVS (4 lines):
>   g++ -DHAVE_CONFIG_H     -I../Source/Include -I../Source/DOH 
> -I../Source/Preproc
> essor -I../Source/Swig -I../Source/Modules 
> -DSWIG_LIB="/usr/local/lib/swig1.3" -
> DLIBDIR="/usr/local/lib" -DRELEASE_SUFFIX=""  -g -O2 -MT Modules/allocate.o 
> -MD
> -MP -MF Modules/.deps/allocate.Tpo -c -o Modules/allocate.o 
> Modules/allocate.cxx
> 
> Slightly modified Automake-1.7.3 (7 lines):
> if g++ -DHAVE_CONFIG_H     -I../Source/Include -I../Source/DOH 
> -I../Source/Prepr
> ocessor -I../Source/Swig -I../Source/Modules 
> -DSWIG_LIB=\"/usr/local/lib/swig1.3
> \" -DLIBDIR=\"/usr/local/lib\" -DRELEASE_SUFFIX=\"\"  -g -O2 -MT 
> Modules/allocat
> e.o -MD -MP -MF "Modules/.deps/allocate.Tpo" -c -o Modules/allocate.o `test 
> -f '
> Modules/allocate.cxx' || echo './'`Modules/allocate.cxx; \
> then mv "Modules/.deps/allocate.Tpo" "Modules/.deps/allocate.Po"; else rm -f 
> "Mo
> dules/.deps/allocate.Tpo"; exit 1; fi
> 
> Automake-1.7.3 (9 lines):
> if g++ -DHAVE_CONFIG_H     -I../Source/Include -I../Source/DOH 
> -I../Source/Prepr
> ocessor -I../Source/Swig -I../Source/Modules 
> -DSWIG_LIB=\"/usr/local/lib/swig1.3
> \" -DLIBDIR=\"/usr/local/lib\" -DRELEASE_SUFFIX=\"\"  -g -O2 -MT 
> Modules/allocat
> e.o -MD -MP -MF "Modules/.deps/allocate.Tpo" \
>    -c -o Modules/allocate.o `test -f 'Modules/allocate.cxx' || echo 
> './'`Modules/
> allocate.cxx; \
> then mv "Modules/.deps/allocate.Tpo" "Modules/.deps/allocate.Po"; \
> else rm -f "Modules/.deps/allocate.Tpo"; exit 1; \
> fi
> 
> The CVS version is an improvement, but doesn't actually solve the problem of 
> producing 
> heaps of junk, so I'm not sure that anything has been gained. A lot has been 
> lost with -s 
> not working.
> 
> As shown the number of lines produced could easily be reduced by simply 
> removing some of 
> the continuation line characters in the if then else block. Perhaps this can 
> be done 
> instead if the Automake developers are not keen on adding an option to either 
> honour or 
> not honour -s.
> 
> One last point about the CVS approach of hiding the real commands is that in 
> the event of 
> something going wrong, it becomes a frustrating debugging exercise when only 
> a subset of 
> what is happening is displayed to the user.
> 
> Cheers
> William
> 
> PS Karl, I've only just noticed this was a private email. Would it not be 
> more appropriate 
> to discuss this on the mailing list to get feedback from others?
> 
> 
> 

> Date: Mon, 21 Apr 2003 11:29:47 -0400
> From: address@hidden (Karl Berry)
> To: address@hidden
> Cc: address@hidden
> Subject: Re: CVS version is not less verbose
> 
> Aha!  I'll skip all my other possible comments and focus on your suggestion:
> 
>     As shown the number of lines produced could easily be reduced by
>     simply removing some of the continuation line characters in the if
>     then else block.
> 
> Excellent point, wish I'd thought of that in the first place! If it was
> all one line:
> if $COMPILE; then foo; else bar; fi
> then I think we'd both be happy.
> 
>     PS Karl, I've only just noticed this was a private email. Would it
>     not be more appropriate to discuss this on the mailing list to get
>     feedback from others?
> 
> I don't mind, either way.  Alexandre forwarded it to me since I wasn't
> on the list, and I didn't think of cc-ing it back to the list.  I think
> it's pretty much Alexandre's decision, anyway :).
> 
> 

> Date: Mon, 21 Apr 2003 20:12:24 +0100
> From: William S Fulton <address@hidden>
> To: Karl Berry <address@hidden>
> CC: address@hidden
> Subject: Re: CVS version is not less verbose
> 
> Karl Berry wrote:
> > Aha!  I'll skip all my other possible comments and focus on your suggestion:
> Hey, I'm interested in your comments on my wayward thoughts, good or bad ;)
> 
> > 
> >     As shown the number of lines produced could easily be reduced by
> >     simply removing some of the continuation line characters in the if
> >     then else block.
> > 
> > Excellent point, wish I'd thought of that in the first place! If it was
> > all one line:
> > if $COMPILE; then foo; else bar; fi
> > then I think we'd both be happy.
> > 
> Okay, that's fine by me. I actually tried for some time to improve it 
> further, but that 
> was the best I could come up with. My shell scripting isn't the best, but I 
> have a gut 
> feeling that it could get better. Especially this bit:
> 
> `test -f 'Modules/allocate.cxx' || echo './'`
> 
> I can't work out why this is needed. Maybe a solution for some operating 
> systems that need 
> the current directory explicitly stated. I was wondering if there is any 
> possibility for 
> replacing it with a make variable which is either set to nothing or './'? Or 
> how about 
> always using './'? It would neaten up the compilation line and reduce the 
> output by half a 
> line or so.
> 
> >     PS Karl, I've only just noticed this was a private email. Would it
> >     not be more appropriate to discuss this on the mailing list to get
> >     feedback from others?
> > 
> > I don't mind, either way.  Alexandre forwarded it to me since I wasn't
> > on the list, and I didn't think of cc-ing it back to the list.  I think
> > it's pretty much Alexandre's decision, anyway :).
> >
> Cool, just curious, I presumed with the fast response that you'd got it from 
> the mailing list.
> 
> Cheers
> William
> 
> 
> 

As an ordinary user, I find all the output frustrating.
It seems to me like it would be best if a minimal amount of information
was displayed while running make, and a .log file is generated with all
of the information for viewing upon error ( or any other reason all the
details need to be known ).

Most people ( like me ) that use the makefiles generated by automake,
don't care much about what automake is doing to get the job done.
The compile command compiler messages would be nice to see.

Bob Rossi