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]>. It seems that I was wrong about the impact to my package. With the update, it seems that default output and 'make -s' output are as intended (i.e. better than before). 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 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
* 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
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: -prefer-pic
Hello Olly,
* Olly Betts wrote on Thu, Jan 10, 2008 at 07:42:16PM CET:
> The output from:
>
> libtool --help --mode=compile
>
> contains:
>
> -prefer-pic try to building PIC objects only
> -prefer-non-pic try to building non-PIC objects only
>
> Firstly, that's poor grammar ("try to build" would be better).
>
> Secondly, this seems to be the full extent of the documentation for
> these options - searching the info manual for "-prefer" doesn't find
> anything. The NEWS file notes they were added in libtool 1.3d "to
> control the generation of PIC/non-PIC code".
Firstly, a patch for both would be cool, and secondly, it's probably not
documented because it doesn't work all that well. ;-)
(Of course, the non-PIC code in shared issue is borked because of the
deplibs_check_method war. That should be revisited at some time and
redone right.)
Thanks for the report,
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 sh
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 > 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
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 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
