Re: CVS version is not less verbose

[Alexandre Duret-Lutz]

>>> "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
> --- Begin Message ---
>
>
>
> Subject: 
>
> Topics
>
>
>
>
> Topics:
>    Re: CVS version is not less verbose
>    Re: CVS version is not less verbose
>    Re: CVS version is not less verbose
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: CVS version is not less verbose
>
>
>
>
> Date: 
>
> Mon, 21 Apr 2003 15:07:29 +0100
>
>
>
>
> 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?
>
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: CVS version is not less verbose
>
>
>
>
> Date: 
>
> Mon, 21 Apr 2003 11:29:47 -0400
>
>
>
>
> 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 :).
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: CVS version is not less verbose
>
>
>
>
> Date: 
>
> Mon, 21 Apr 2003 20:12:24 +0100
>
>
>
>
> 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
>
>
>
>
> --- End Message ---