Re: make -s
On Mon, Jan 14, 2008 at 11:06:00PM +0100, Ralf Wildenhues wrote: * Peter O'Gorman wrote on Mon, Jan 14, 2008 at 11:00:35PM CET: Ralf Wildenhues wrote: Since repeatedly nobody stepped forward to do this, I wrote that patch myself now. OK to apply to HEAD? Yes. Thank you. Done, thanks! Thank you Ralf. I owe you one. Bob Rossi
Re: make -s
* Ralf Wildenhues wrote on Thu, Jan 10, 2008 at 08:29:33AM CET:
For whatever output is left done by libtool I expect that whoever want's
it silenced hard enough will have enough motivation to send a patch to
libtool-patches@gnu.org.
Since repeatedly nobody stepped forward to do this, I wrote that patch
myself now. OK to apply to HEAD?
Cheers,
Ralf
2008-01-14 Ralf Wildenhues [EMAIL PROTECTED]
Silence all non-warning output from `libtool --silent'.
* libltdl/config/ltmain.m4sh (func_generate_dlsyms)
(func_extract_archives, func_mode_link): Use func_verbose
instead of func_echo for all non-warning output.
Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.95
diff -u -r1.95 ltmain.m4sh
--- libltdl/config/ltmain.m4sh 12 Jan 2008 13:58:14 - 1.95
+++ libltdl/config/ltmain.m4sh 14 Jan 2008 21:19:24 -
@@ -879,7 +879,7 @@
func_show_eval $RM $nlist ${nlist}S ${nlist}T
# Parse the name list into a source file.
- func_echo creating $output_objdir/$my_dlsyms
+ func_verbose creating $output_objdir/$my_dlsyms
$opt_dry_run || $ECHO $output_objdir/$my_dlsyms \
/* $my_dlsyms - symbol resolution table for \`$my_outputname' dlsym emulation.
*/
@@ -893,14 +893,14 @@
if test $dlself = yes; then
- func_echo generating symbol list for \`$output'
+ func_verbose generating symbol list for \`$output'
$opt_dry_run || echo ': @PROGRAM@ ' $nlist
# Add our own program objects to the symbol list.
progfiles=`$ECHO X$objs$old_deplibs | $SP2NL | $Xsed -e $lo2o |
$NL2SP`
for progfile in $progfiles; do
- func_echo extracting global C symbols from \`$progfile'
+ func_verbose extracting global C symbols from \`$progfile'
$opt_dry_run || eval $NM $progfile | $global_symbol_pipe
'$nlist'
done
@@ -947,7 +947,7 @@
fi
for dlprefile in $dlprefiles; do
- func_echo extracting global C symbols from \`$dlprefile'
+ func_verbose extracting global C symbols from \`$dlprefile'
func_basename $dlprefile
name=$func_basename_result
$opt_dry_run || {
@@ -1159,7 +1159,7 @@
case $host in
*-darwin*)
- func_echo Extracting $my_xabs
+ func_verbose Extracting $my_xabs
# Do not bother doing anything if just a dry run
$opt_dry_run || {
darwin_orig_dir=`pwd`
@@ -1171,7 +1171,7 @@
if test -n $darwin_arches; then
darwin_arches=`$ECHO $darwin_arches | $SED -e 's/.*are://'`
darwin_arch=
- func_echo $darwin_base_archive has multiple architectures
$darwin_arches
+ func_verbose $darwin_base_archive has multiple architectures
$darwin_arches
for darwin_arch in $darwin_arches ; do
func_mkdir_p unfat-$$/${darwin_base_archive}-${darwin_arch}
lipo -thin $darwin_arch -output
unfat-$$/${darwin_base_archive}-${darwin_arch}/${darwin_base_archive}
${darwin_archive}
@@ -4655,13 +4655,13 @@
# If the library has no export list, then create one now
if test -f $output_objdir/$soname-def; then :
else
- func_echo extracting exported symbol list from \`$soname'
+ func_verbose extracting exported symbol list from \`$soname'
func_execute_cmds $extract_expsyms_cmds 'exit $?'
fi
# Create $newlib
if test -f $output_objdir/$newlib; then :; else
- func_echo generating import library for \`$soname'
+ func_verbose generating import library for \`$soname'
func_execute_cmds $old_archive_from_expsyms_cmds 'exit $?'
fi
# make sure the library variables are pointing to the new library
@@ -5982,7 +5982,7 @@
# Prepare the list of exported symbols
if test -z $export_symbols; then
if test $always_export_symbols = yes || test -n
$export_symbols_regex; then
- func_echo generating symbol list for \`$libname.la'
+ func_verbose generating symbol list for \`$libname.la'
export_symbols=$output_objdir/$libname.exp
$opt_dry_run || $RM $export_symbols
cmds=$export_symbols_cmds
@@ -5996,7 +5996,7 @@
skipped_export=false
else
# The command line is too long to execute in one step.
- func_echo using reloadable object file for export list...
+ func_verbose using reloadable object file for export list...
skipped_export=:
# Break out early, otherwise skipped_export may be
# set to false by a later but shorter cmd.
@@ -6019,7 +6019,7 @@
if test X$skipped_export != X: test -n
Re: make -s
Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Thu, Jan 10, 2008 at 08:29:33AM CET: For whatever output is left done by libtool I expect that whoever want's it silenced hard enough will have enough motivation to send a patch to libtool-patches@gnu.org. Since repeatedly nobody stepped forward to do this, I wrote that patch myself now. OK to apply to HEAD? Yes. Thank you. Peter -- Peter O'Gorman http://pogma.com
Re: make -s
On Sunday 13 January 2008 17:46, Ralf Wildenhues wrote: * Richard Hacker wrote on Fri, Jan 11, 2008 at 01:21:50PM CET: However, libtool is responsible for parsing *make's *FLAGS Now, this contradicts your statement (*) above, no? Oppps, my mistake. Sorry for confusing everyone :-( No, as you correctly read and interpreted, I meant to say that libtool should NOT parse their caller's *FLAGS. The caller (i.e. automake in this case) should be responsible for calling its subcommands with their respective silent flags set as far as they exist. Think of the case when a new supermake enters the scene and the authors of all the various tools that it calls have to implement yet another SUPERMAKEFLAGS. This concept does not scale well. If `make -s' were to influence libtool verbosity, there are several choices to implement this: - inside the libtool script, parse MAKEFLAGS poor IMHO - automake hackery that puts necessary code in Makefile.in so that upon `make -s', libtool is called with --silent better The second choice leaves users of make-without-automake in the cold, ... It is the duty of the various *make developers to implement a silent mode... but my assumption is that none of you care about it (of course they could always copy that implementation). It also carries the burden of larger Makefiles, likely even more verbose output when `make' is issued without `-s'. Why should the output of a make without '-s' be larger? I do not see this necessity. The problem of implementing the required logic in a Makefile is that, while it is quite cheap to do with GNU make, I only see ugly solutions that work with portable make. They either - require the choice of silency to be made at configure time already, Poor IMHO. make's -s switch is dynamic in nature and this spirit should be kept with a silent or not silent implementation is planned If someone sees a way to avoid these, I'd love to hear about it. There should be some if make_is_silent; AM_LIBTOOLFLAGS += --silent; endif construct inside Makefile.in. However, I have not seen any if...endif constructs in Makefile.in as a starting point for writing portable make commands. FWIW, here's a patch that goes the ugly design way of implementing this in libtool, which I think is portable. At least it works inside the autoconf, automake, libtool toolset. This is a very common setup. But thanks for the patch. I'll be using it shortly. It is more professional than my one ;-) Regards - Richard ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
* Richard Hacker wrote on Mon, Jan 14, 2008 at 10:24:12AM CET: On Sunday 13 January 2008 17:46, Ralf Wildenhues wrote: * Richard Hacker wrote on Fri, Jan 11, 2008 at 01:21:50PM CET: However, libtool is responsible for parsing *make's *FLAGS Now, this contradicts your statement (*) above, no? Oppps, my mistake. Sorry for confusing everyone :-( No, as you correctly read and interpreted, I meant to say that libtool should NOT parse their caller's *FLAGS. The caller (i.e. automake in this case) should be responsible for calling its subcommands with their respective silent flags set as far as they exist. Think of the case when a new supermake enters the scene and the authors of all the various tools that it calls have to implement yet another SUPERMAKEFLAGS. This concept does not scale well. Good. So we're in violent agreement here. [... putting the silencing code in automake ...] also carries the burden of larger Makefiles, likely even more verbose output when `make' is issued without `-s'. Why should the output of a make without '-s' be larger? I do not see this necessity. Then I welcome you to write a patch for Automake implementing this, or even just one that shows how it would work in the Makefile. I would be very thankful indeed. What I've been able to come up with is something like am__lt_silent = `for f in $$MAKEFLAGS; do case $$f in *=* | --[!s]*);; \ *s*) echo --silent;; esac done` LIBTOOL = $(SHELL) $(top_builddir)/libtool $(am__lt_silent) but that - generates even more visual clutter if *not* doing `make -s', - and spawns another subshell upon each libtool invocation. Granted, this could be eliminated like this am__lt_silent = for f in $$MAKEFLAGS; do case $$f in *=* | --[!s]*) silent=;; \ *s*) silent=--silent;; esac done; LIBTOOL = $(am__lt_silent) $(SHELL) $(top_builddir)/libtool $$silent but wow, look at how ugly your typical non-silent make command output has become at this point. The problem of implementing the required logic in a Makefile is that, while it is quite cheap to do with GNU make, I only see ugly solutions that work with portable make. They either - require the choice of silency to be made at configure time already, Poor IMHO. make's -s switch is dynamic in nature and this spirit should be kept with a silent or not silent implementation is planned Agreed. If someone sees a way to avoid these, I'd love to hear about it. There should be some if make_is_silent; AM_LIBTOOLFLAGS += --silent; endif construct inside Makefile.in. However, I have not seen any if...endif constructs in Makefile.in as a starting point for writing portable make commands. Well, because portably-wise, such a construct does not exist to my knowledge. Some of the older make's don't have conditionals, and for the newer, at least two different syntax forms exist. That's one reason why the whole `configure' thingy came to be in the first place. My point the whole time is: it is not possible to fix this nicely in Automake. Fixing this uglily in Libtool is, well, ugly. On the other hand, alias make_s=make -s LIBTOOLFLAGS=--silent is pretty cheap, but requires the user to get up and invest half an inch of effort. So what to do? FWIW, here's a patch that goes the ugly design way of implementing this in libtool, which I think is portable. At least it works inside the autoconf, automake, libtool toolset. This is a very common setup. Yep. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
* Ralf Wildenhues wrote on Thu, Jan 10, 2008 at 08:29:33AM CET:
For whatever output is left done by libtool I expect that whoever want's
it silenced hard enough will have enough motivation to send a patch to
[EMAIL PROTECTED].
Since repeatedly nobody stepped forward to do this, I wrote that patch
myself now. OK to apply to HEAD?
Cheers,
Ralf
2008-01-14 Ralf Wildenhues [EMAIL PROTECTED]
Silence all non-warning output from `libtool --silent'.
* libltdl/config/ltmain.m4sh (func_generate_dlsyms)
(func_extract_archives, func_mode_link): Use func_verbose
instead of func_echo for all non-warning output.
Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.95
diff -u -r1.95 ltmain.m4sh
--- libltdl/config/ltmain.m4sh 12 Jan 2008 13:58:14 - 1.95
+++ libltdl/config/ltmain.m4sh 14 Jan 2008 21:19:24 -
@@ -879,7 +879,7 @@
func_show_eval $RM $nlist ${nlist}S ${nlist}T
# Parse the name list into a source file.
- func_echo creating $output_objdir/$my_dlsyms
+ func_verbose creating $output_objdir/$my_dlsyms
$opt_dry_run || $ECHO $output_objdir/$my_dlsyms \
/* $my_dlsyms - symbol resolution table for \`$my_outputname' dlsym emulation.
*/
@@ -893,14 +893,14 @@
if test $dlself = yes; then
- func_echo generating symbol list for \`$output'
+ func_verbose generating symbol list for \`$output'
$opt_dry_run || echo ': @PROGRAM@ ' $nlist
# Add our own program objects to the symbol list.
progfiles=`$ECHO X$objs$old_deplibs | $SP2NL | $Xsed -e $lo2o |
$NL2SP`
for progfile in $progfiles; do
- func_echo extracting global C symbols from \`$progfile'
+ func_verbose extracting global C symbols from \`$progfile'
$opt_dry_run || eval $NM $progfile | $global_symbol_pipe
'$nlist'
done
@@ -947,7 +947,7 @@
fi
for dlprefile in $dlprefiles; do
- func_echo extracting global C symbols from \`$dlprefile'
+ func_verbose extracting global C symbols from \`$dlprefile'
func_basename $dlprefile
name=$func_basename_result
$opt_dry_run || {
@@ -1159,7 +1159,7 @@
case $host in
*-darwin*)
- func_echo Extracting $my_xabs
+ func_verbose Extracting $my_xabs
# Do not bother doing anything if just a dry run
$opt_dry_run || {
darwin_orig_dir=`pwd`
@@ -1171,7 +1171,7 @@
if test -n $darwin_arches; then
darwin_arches=`$ECHO $darwin_arches | $SED -e 's/.*are://'`
darwin_arch=
- func_echo $darwin_base_archive has multiple architectures
$darwin_arches
+ func_verbose $darwin_base_archive has multiple architectures
$darwin_arches
for darwin_arch in $darwin_arches ; do
func_mkdir_p unfat-$$/${darwin_base_archive}-${darwin_arch}
lipo -thin $darwin_arch -output
unfat-$$/${darwin_base_archive}-${darwin_arch}/${darwin_base_archive}
${darwin_archive}
@@ -4655,13 +4655,13 @@
# If the library has no export list, then create one now
if test -f $output_objdir/$soname-def; then :
else
- func_echo extracting exported symbol list from \`$soname'
+ func_verbose extracting exported symbol list from \`$soname'
func_execute_cmds $extract_expsyms_cmds 'exit $?'
fi
# Create $newlib
if test -f $output_objdir/$newlib; then :; else
- func_echo generating import library for \`$soname'
+ func_verbose generating import library for \`$soname'
func_execute_cmds $old_archive_from_expsyms_cmds 'exit $?'
fi
# make sure the library variables are pointing to the new library
@@ -5982,7 +5982,7 @@
# Prepare the list of exported symbols
if test -z $export_symbols; then
if test $always_export_symbols = yes || test -n
$export_symbols_regex; then
- func_echo generating symbol list for \`$libname.la'
+ func_verbose generating symbol list for \`$libname.la'
export_symbols=$output_objdir/$libname.exp
$opt_dry_run || $RM $export_symbols
cmds=$export_symbols_cmds
@@ -5996,7 +5996,7 @@
skipped_export=false
else
# The command line is too long to execute in one step.
- func_echo using reloadable object file for export list...
+ func_verbose using reloadable object file for export list...
skipped_export=:
# Break out early, otherwise skipped_export may be
# set to false by a later but shorter cmd.
@@ -6019,7 +6019,7 @@
if test X$skipped_export != X: test -n
Re: make -s
Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Thu, Jan 10, 2008 at 08:29:33AM CET: For whatever output is left done by libtool I expect that whoever want's it silenced hard enough will have enough motivation to send a patch to [EMAIL PROTECTED]. Since repeatedly nobody stepped forward to do this, I wrote that patch myself now. OK to apply to HEAD? Yes. Thank you. Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
* Peter O'Gorman wrote on Mon, Jan 14, 2008 at 11:00:35PM CET: Ralf Wildenhues wrote: Since repeatedly nobody stepped forward to do this, I wrote that patch myself now. OK to apply to HEAD? Yes. Thank you. Done, thanks! Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
On Mon, 14 Jan 2008, Ralf Wildenhues wrote: * Ralf Wildenhues wrote on Thu, Jan 10, 2008 at 08:29:33AM CET: For whatever output is left done by libtool I expect that whoever want's it silenced hard enough will have enough motivation to send a patch to [EMAIL PROTECTED]. Since repeatedly nobody stepped forward to do this, I wrote that patch myself now. OK to apply to HEAD? I think that this patch is ok but it is a major change so I think that we should hear from several people before applying it. This change will impact my own package since my package applies --silent by default in order to intentionally obtain a medium level of output. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
On Thursday 10 January 2008 21:30, Ralf Wildenhues wrote: If you want all tools silenced which are called by make, then I suggest to simply use make /dev/null || make well, we're after the automatic output going away, not intended output. So what's intended output? I think that the output should be similar to make -s. This is also not completely quiet, compiler warnings and the like are shown. It just means that the make commands should not be shown, whereas the output of the commands are very well. This reduces much of the 'make noise' and reduces the output to compiler warnings and errors. Quite honestly, I recently oversaw a compiler warning due to noise because I was on the command line and not in an editor. Should libtool parse their $TOOLFLAGS too? Good point. No not really. Why should the tools parse their caller's flags? Quite frankly, make should be the one that calls the various tools with their respective --silent flag set, not the other way 'round, right? If all you want is libtool to go silent globally in your package then what about just AC_SUBST([AM_LIBTOOLFLAGS], [--silent]) This is not the intention of the root of this discussion. Just as well as make /dev/null 21 is also not the point. If libtool complains, it should show it, whether it be stdout or stderr, it should all be shown. However, the ugly ;) 'g++ -DHAVE_CONFIG_H -I. -I. -I. -Wall -g -O2 .' that libtool calls is not really essential to the programmer when (s)he calls make -s. True, my editor should pick up these compiler warnings, but funnily enough, my vim allways ends up with a blank buffer after doing :make but not with ':make -s' when I use my patch to silence libtool. So, here is my modest opinion. If I as a programmer call *) 'make' on its own, it should show its commands as well as their output *) 'make -s', it should not show the commands it calls, only the output of these. However, libtool is responsible for parsing *make's *FLAGS Cheers - Richard ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
On Thursday 10 January 2008 08:29, Ralf Wildenhues wrote:
For whatever output is left done by libtool I expect that whoever want's
it silenced hard enough will have enough motivation to send a patch to
libtool-patches@gnu.org.
That shouldn't bee too difficult.
As a hint, make adds 's' to the environment variable MAKEFLAGS:
MAKEFLAGS=s
MFLAGS=-s also exists, but its use seems to be superceded by MAKEFLAGS
When I change ltmain.sh using the following patch, it seems to work. I am
using
# libtool --version
ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)
I hope this patch is portable I am certainly no expert in portability!
patch start
--- old/ltmain.sh 2006-11-25 12:34:55.0 +0100
+++ /usr/share/libtool/ltmain.sh2008-01-10 13:28:59.0 +0100
@@ -384,6 +384,15 @@
done
func_extract_archives_result=$my_oldobjs
}
+
+func_is_make_silent ()
+{
+case $1 in
+*s*) true;;
+*) false;;
+esac
+}
+
# End of Shell function definitions
#
@@ -392,6 +401,12 @@
disable_libs=no
+if func_is_make_silent $MAKEFLAGS
+then
+ show=:
+ preserve_args=$preserve_args $arg
+fi
+
# Parse our command line options once, thoroughly.
while test $# -gt 0
do
patch end
- Richard
Re: make -s
On Thu, Jan 10, 2008 at 04:15:12PM -0500, Mike Frysinger wrote: On Thursday 10 January 2008, Ralf Wildenhues wrote: * Mike Frysinger wrote on Thu, Jan 10, 2008 at 08:58:09PM CET: On Thursday 10 January 2008, Ralf Wildenhues wrote: What I meant was: even with make -s LIBTOOLFLAGS=--silent there will be some leftover output done by libtool. If somebody wants to fix that, be invited to provide a (complete) patch (best including testsuite amend; the stresstest in Libtool HEAD would probably come in handy). If you want all tools silenced which are called by make, then I suggest to simply use make /dev/null || make well, we're after the automatic output going away, not intended output. So what's intended output? That by make, libtool is apparently not. What about makeinfo, texi2dvi, dvips? autoconf/aclocal/automake reruns, configure reruns? Are you suggesting each of them parse $MAKEFLAGS and go silent with that, too? libtool need not be invoked by make alone. There are multitudinous other build systems, some of which call libtool at times. Should libtool parse their $TOOLFLAGS too? I merely think that MAKEFLAGS is for make, and other flags should be for other programs. And hey, that's just my personal opinion, not cast in stone or anything; but I would like to be shown why another choice is better. i think we're focusing on the big offenders here. libtool is certainly much more prevalent than any other tool cited here when combined with autotools. taking that into consideration, the fact that libtool outputs status information that amounts pretty closely (almost exactly) to what make itself would output, the idea of having it be autosilenced according to -s is a common (and logical) expectation for people. i'm not saying this is grounds for this must be done!, just putting it out there. Exactly, I would think most people would not expect the current behavior. I would say Hey, I told make to be quit, but it's not. Ingorance is bliss. Bob Rossi
Re: make -s
On Thu, 10 Jan 2008, Bob Rossi wrote: Well, I might be over simplifying things because I don't understand the big picture. When I type 'make -s' I assume that the compiler commands that make kicks off will not be sent to stdout/stderr. I do expect that if the user has some stuff in the Makefile that prints to stdout/stderr that it would show up there. Yes, all 'make -s' is supposed to do is to cause make not to provide information about what it is doing. It should not influence anything else. The only contract that libtool should offer is that if --silent is supplied, it should similarly not provide information about what it is doing. It should only provide information about what has gone wrong. Unfortunately, sometimes it is very difficult to decipher an error message unless you know the precise action which was being performed. The automake project would be a better place to add extra smarts for a more silent build when using libtool. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: make -s
On Thursday 10 January 2008 08:29, Ralf Wildenhues wrote:
For whatever output is left done by libtool I expect that whoever want's
it silenced hard enough will have enough motivation to send a patch to
[EMAIL PROTECTED].
That shouldn't bee too difficult.
As a hint, make adds 's' to the environment variable MAKEFLAGS:
MAKEFLAGS=s
MFLAGS=-s also exists, but its use seems to be superceded by MAKEFLAGS
When I change ltmain.sh using the following patch, it seems to work. I am
using
# libtool --version
ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)
I hope this patch is portable I am certainly no expert in portability!
patch start
--- old/ltmain.sh 2006-11-25 12:34:55.0 +0100
+++ /usr/share/libtool/ltmain.sh2008-01-10 13:28:59.0 +0100
@@ -384,6 +384,15 @@
done
func_extract_archives_result=$my_oldobjs
}
+
+func_is_make_silent ()
+{
+case $1 in
+*s*) true;;
+*) false;;
+esac
+}
+
# End of Shell function definitions
#
@@ -392,6 +401,12 @@
disable_libs=no
+if func_is_make_silent $MAKEFLAGS
+then
+ show=:
+ preserve_args=$preserve_args $arg
+fi
+
# Parse our command line options once, thoroughly.
while test $# -gt 0
do
patch end
- Richard
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
Hello Richard, * Richard Hacker wrote on Thu, Jan 10, 2008 at 01:39:31PM CET: On Thursday 10 January 2008 08:29, Ralf Wildenhues wrote: For whatever output is left done by libtool I expect that whoever want's it silenced hard enough will have enough motivation to send a patch to [EMAIL PROTECTED]. That shouldn't bee too difficult. Misunderstanding again, this time my fault, sorry. What I meant was: even with make -s LIBTOOLFLAGS=--silent there will be some leftover output done by libtool. If somebody wants to fix that, be invited to provide a (complete) patch (best including testsuite amend; the stresstest in Libtool HEAD would probably come in handy). If you want all tools silenced which are called by make, then I suggest to simply use make /dev/null || make Eric already mentioned the portability issue with your patch. Hope that helps. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
On Thursday 10 January 2008, Ralf Wildenhues wrote: * Richard Hacker wrote on Thu, Jan 10, 2008 at 01:39:31PM CET: On Thursday 10 January 2008 08:29, Ralf Wildenhues wrote: For whatever output is left done by libtool I expect that whoever want's it silenced hard enough will have enough motivation to send a patch to [EMAIL PROTECTED]. That shouldn't bee too difficult. Misunderstanding again, this time my fault, sorry. What I meant was: even with make -s LIBTOOLFLAGS=--silent there will be some leftover output done by libtool. If somebody wants to fix that, be invited to provide a (complete) patch (best including testsuite amend; the stresstest in Libtool HEAD would probably come in handy). If you want all tools silenced which are called by make, then I suggest to simply use make /dev/null || make well, we're after the automatic output going away, not intended output. but i guess you could (reasonably) argue that status messages intended to be seen should be sent to stderr, not stdout ... -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
* Mike Frysinger wrote on Thu, Jan 10, 2008 at 08:58:09PM CET: On Thursday 10 January 2008, Ralf Wildenhues wrote: What I meant was: even with make -s LIBTOOLFLAGS=--silent there will be some leftover output done by libtool. If somebody wants to fix that, be invited to provide a (complete) patch (best including testsuite amend; the stresstest in Libtool HEAD would probably come in handy). If you want all tools silenced which are called by make, then I suggest to simply use make /dev/null || make well, we're after the automatic output going away, not intended output. So what's intended output? That by make, libtool is apparently not. What about makeinfo, texi2dvi, dvips? autoconf/aclocal/automake reruns, configure reruns? Are you suggesting each of them parse $MAKEFLAGS and go silent with that, too? libtool need not be invoked by make alone. There are multitudinous other build systems, some of which call libtool at times. Should libtool parse their $TOOLFLAGS too? I merely think that MAKEFLAGS is for make, and other flags should be for other programs. And hey, that's just my personal opinion, not cast in stone or anything; but I would like to be shown why another choice is better. If all you want is libtool to go silent globally in your package then what about just AC_SUBST([AM_LIBTOOLFLAGS], [--silent]) in configure.ac. but i guess you could (reasonably) argue that status messages intended to be seen should be sent to stderr, not stdout ... Well that's another point. FWIW, for me, make output is not read by me (unless I debug a build), but parsed by my editor. It's good at throwing away what I don't want to see. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
On Thu, Jan 10, 2008 at 09:30:21PM +0100, Ralf Wildenhues wrote: * Mike Frysinger wrote on Thu, Jan 10, 2008 at 08:58:09PM CET: On Thursday 10 January 2008, Ralf Wildenhues wrote: What I meant was: even with make -s LIBTOOLFLAGS=--silent there will be some leftover output done by libtool. If somebody wants to fix that, be invited to provide a (complete) patch (best including testsuite amend; the stresstest in Libtool HEAD would probably come in handy). If you want all tools silenced which are called by make, then I suggest to simply use make /dev/null || make well, we're after the automatic output going away, not intended output. So what's intended output? That by make, libtool is apparently not. What about makeinfo, texi2dvi, dvips? autoconf/aclocal/automake reruns, configure reruns? Are you suggesting each of them parse $MAKEFLAGS and go silent with that, too? libtool need not be invoked by make alone. There are multitudinous other build systems, some of which call libtool at times. Should libtool parse their $TOOLFLAGS too? I merely think that MAKEFLAGS is for make, and other flags should be for other programs. And hey, that's just my personal opinion, not cast in stone or anything; but I would like to be shown why another choice is better. Well, I might be over simplifying things because I don't understand the big picture. When I type 'make -s' I assume that the compiler commands that make kicks off will not be sent to stdout/stderr. I do expect that if the user has some stuff in the Makefile that prints to stdout/stderr that it would show up there. Now, before I started using libtool and I only used automake, when I typed 'make -s' I didn't see any g++ or linker commands. After I added libtool, some g++ commands started to appear. I thought it would seem natural that the -s to the Makefile would be supported by the libtool generated Makefile code. It was just my This is how things should intuitively work reaction. Thanks, Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
Bob Rossi wrote: Well, I might be over simplifying things because I don't understand the big picture. When I type 'make -s' I assume that the compiler commands that make kicks off will not be sent to stdout/stderr. You do not see the compiler commands kicked off by make, you see the compiler commands kicked off by libtool... This has been discussed before and is, IIRC, the reason that Ralf introduced LIBTOOLFLAGS in automake. Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
On Thursday 10 January 2008, Ralf Wildenhues wrote: * Mike Frysinger wrote on Thu, Jan 10, 2008 at 08:58:09PM CET: On Thursday 10 January 2008, Ralf Wildenhues wrote: What I meant was: even with make -s LIBTOOLFLAGS=--silent there will be some leftover output done by libtool. If somebody wants to fix that, be invited to provide a (complete) patch (best including testsuite amend; the stresstest in Libtool HEAD would probably come in handy). If you want all tools silenced which are called by make, then I suggest to simply use make /dev/null || make well, we're after the automatic output going away, not intended output. So what's intended output? That by make, libtool is apparently not. What about makeinfo, texi2dvi, dvips? autoconf/aclocal/automake reruns, configure reruns? Are you suggesting each of them parse $MAKEFLAGS and go silent with that, too? libtool need not be invoked by make alone. There are multitudinous other build systems, some of which call libtool at times. Should libtool parse their $TOOLFLAGS too? I merely think that MAKEFLAGS is for make, and other flags should be for other programs. And hey, that's just my personal opinion, not cast in stone or anything; but I would like to be shown why another choice is better. i think we're focusing on the big offenders here. libtool is certainly much more prevalent than any other tool cited here when combined with autotools. taking that into consideration, the fact that libtool outputs status information that amounts pretty closely (almost exactly) to what make itself would output, the idea of having it be autosilenced according to -s is a common (and logical) expectation for people. i'm not saying this is grounds for this must be done!, just putting it out there. there is some precedence here with tools automatically checking MAKEFLAGS for the s flag and tweaking their status output, but those tend to be one-off things integrated into existing build systems. the other common behavior in the world is letting the Makefile itself decide. since libtool/automake are integrated tightly, another direction to take things would be to have automake's default behavior conditionally execute libtool with --silent depending on MAKEFLAGS. while POSIX dictates the portability of MAKEFLAGS, autotools is a superset of such things, so i dont know how much that comes into play with these decisions. If all you want is libtool to go silent globally in your package then what about just AC_SUBST([AM_LIBTOOLFLAGS], [--silent]) in configure.ac. but i want make cake and it too ! :) -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
On Thu, Jan 10, 2008 at 04:15:12PM -0500, Mike Frysinger wrote: On Thursday 10 January 2008, Ralf Wildenhues wrote: * Mike Frysinger wrote on Thu, Jan 10, 2008 at 08:58:09PM CET: On Thursday 10 January 2008, Ralf Wildenhues wrote: What I meant was: even with make -s LIBTOOLFLAGS=--silent there will be some leftover output done by libtool. If somebody wants to fix that, be invited to provide a (complete) patch (best including testsuite amend; the stresstest in Libtool HEAD would probably come in handy). If you want all tools silenced which are called by make, then I suggest to simply use make /dev/null || make well, we're after the automatic output going away, not intended output. So what's intended output? That by make, libtool is apparently not. What about makeinfo, texi2dvi, dvips? autoconf/aclocal/automake reruns, configure reruns? Are you suggesting each of them parse $MAKEFLAGS and go silent with that, too? libtool need not be invoked by make alone. There are multitudinous other build systems, some of which call libtool at times. Should libtool parse their $TOOLFLAGS too? I merely think that MAKEFLAGS is for make, and other flags should be for other programs. And hey, that's just my personal opinion, not cast in stone or anything; but I would like to be shown why another choice is better. i think we're focusing on the big offenders here. libtool is certainly much more prevalent than any other tool cited here when combined with autotools. taking that into consideration, the fact that libtool outputs status information that amounts pretty closely (almost exactly) to what make itself would output, the idea of having it be autosilenced according to -s is a common (and logical) expectation for people. i'm not saying this is grounds for this must be done!, just putting it out there. Exactly, I would think most people would not expect the current behavior. I would say Hey, I told make to be quit, but it's not. Ingorance is bliss. Bob Rossi ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
On Thu, 10 Jan 2008, Bob Rossi wrote: Well, I might be over simplifying things because I don't understand the big picture. When I type 'make -s' I assume that the compiler commands that make kicks off will not be sent to stdout/stderr. I do expect that if the user has some stuff in the Makefile that prints to stdout/stderr that it would show up there. Yes, all 'make -s' is supposed to do is to cause make not to provide information about what it is doing. It should not influence anything else. The only contract that libtool should offer is that if --silent is supplied, it should similarly not provide information about what it is doing. It should only provide information about what has gone wrong. Unfortunately, sometimes it is very difficult to decipher an error message unless you know the precise action which was being performed. The automake project would be a better place to add extra smarts for a more silent build when using libtool. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
Hello Bob, * Bob Rossi wrote on Wed, Jan 09, 2008 at 08:52:20PM CET: When I do a 'make -s', I usually get no output from the compiler commands. However with libtool, when it goes into, mkdir .libs then I see the compiler output. To me, you speak in riddles. Please just post what command you type, what is output, and what you expect it to output instead. ;-) Ah, and which Automake and Libtool versions you use. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
On Wednesday 09 January 2008, Ralf Wildenhues wrote: * Bob Rossi wrote on Wed, Jan 09, 2008 at 08:52:20PM CET: When I do a 'make -s', I usually get no output from the compiler commands. However with libtool, when it goes into, mkdir .libs then I see the compiler output. To me, you speak in riddles. Please just post what command you type, what is output, and what you expect it to output instead. ;-) i figured it was a known issue that no one cared about. libtool is quite verbose in its running and will output stuff irregardless of the verbose mode make itself is running. take any package that uses libtool and run: make -s if you see any output at all about commands being run, it is incorrect. the request is to have the --silent flag passed automatically to libtool if the -s flag is passed to make. Ah, and which Automake and Libtool versions you use. any version at all should behave the same -mike signature.asc Description: This is a digitally signed message part. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: make -s
Hello Mike, * Mike Frysinger wrote on Wed, Jan 09, 2008 at 10:17:45PM CET: the request is to have the --silent flag passed automatically to libtool if the -s flag is passed to make. alias 'make_s=make -s LIBTOOLFLAGS=--silent' For whatever output is left done by libtool I expect that whoever want's it silenced hard enough will have enough motivation to send a patch to [EMAIL PROTECTED]. Thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
