"Alfred M. Szmidt" <a...@gnu.org> wrote on 2010/01/29 17:47:40: > > > I was refering to AM_SILENT_RULES, which supresses `make all' > > output; so this is not a very controversial topic, it is already > > in automake and used by several projects. Would you like to work > > on this feature? The maintainers can't accept a patch that > > doesn't exist after all... > > I am afraid I not very handy with the program language skills > needed for this. The best I can do is a small patch to ltmain.sh > for the most trivial part. Getting rid of the install msgs is over > my head. > > You don't need that much programming skills to fix this, infact, all > the scaffolding is in place. Take a look in automake/lib/am/progs.am > and automake/lib/am/script.am, and the %SILENT% macro; you'd need to > replace occurences of `echo' with a variable (since we cannot just use > @ to silence the rules), that expands to either : (though, I think > "INSTALL file" would be nicer than complete silence) or echo depending > on if are using V=0 or V=1.
I am sorry, I don't have the time to invest learning the ins of autotools. > > Index: ltmain.sh > =================================================================== > --- ltmain.sh (revision 57662) > +++ ltmain.sh (working copy) > @@ -2028,7 +2028,7 @@ > relink_command=`$ECHO "X$relink_command" | $Xsed -e > "s...@inst_prefix_dir@%%"` > fi > > - func_warning "relinking \`$file'" > + $opt_silent || func_warning "relinking \`$file'" > > The problem with this approach is that ltmain.sh is part of libtool, How is that a problem? libtool also needs fixing and this was what I could do. > and doen't inherit (as far as I remeber) and of the rule you pass to > automake/make. So one would need to pass down something via automake > to libtool, which might get cumbersome. :-( uhmm, --silent needs to be passed otherwise nothing would be silent in libtool. At least passing --silent directly to libtool works :) > > Also, you'd probobly want to put the check in func_warning anyway, that > way you'd silence all invocations of func_warning. No, real warnings should be displayed. These two are not warnings but a notice/info only. > > Sadly, I don't have the source here to whip up a patch; but it is a > easy patch that I'm confident you can do by yourself :-) I think I just did, I don't see another coming.