Ralf Wildenhues <ralf.wildenh...@gmx.de> wrote on 2010/01/30 00:34:17:
>
> Hello,
>
> * Joakim Tjernlund wrote on Fri, Jan 29, 2010 at 09:05:07AM CET:
> >
> > Is there a reason why the install target doesn't respect make -s?
> >
> > I would really like to see autotools and libtool respect make -s.
> > When a developer asks for a silent build in order to catch problems
> > all one should see is real warnings and problems.
>
> Just to address a few of the questions, suggestions, and inaccuracies
> mentioned in this thread.
>
> First off, `make -s' is both POSIX and portable. Conceptually, `make
> -s' has nothing to do with the `silent-rules' option that recent
Exactly, and I am asking for autotools/libtool not to output
anything that isn't a real warning/error when when -s is passed to make.
After all, it is custom that stderr is reserved for errors/warnings only.
> Automakes provide. The difference between `make -s' and
> make >/dev/null
>
> is that standard output from invoked commands and the one-line note
> about invoking make in a subdirectory is not filtered.
>
> For a long time (long long before silent-rules came along), some of the
> more complex rules generated by Automake would mostly operate silently,
> then echo part of their commands before executing them. Examples are
> most rules updated at `make install' time, the .texi.info rule, and
> others which are fairly complex. This is mostly helpful to users, as
> the exact install rules are hard to read; `make -n install' can let you
> appreciate all the ugliness.
>
> With these rules, automake follows a rough rule that it outputs the
> "interesting" command in a single line, with one space preceding it.
> So, one way to avoid seeing this stuff would be, e.g.,
> make -s install | grep -v '^ [^ ]'
>
> If you additionally would like to not see output from libtool, pass
> LIBTOOLFLAGS=--silent
I do so but still see those msgs. It just occurred to me
that ltmain.sh could change those line from func_warning
to func_verbose instead:
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'"
+ func_verbose "relinking \`$file'"
func_show_eval "$relink_command" \
'func_fatal_error "error: relink \`$file'\'' with the above command
before installing it"'
fi
@@ -2269,7 +2269,7 @@
done
test -n "$future_libdirs" && \
- func_warning "remember to run \`$progname --finish$future_libdirs'"
+ func_verbose "remember to run \`$progname --finish$future_libdirs'"
if test -n "$current_libdirs"; then
# Maybe just do a dry run.
>
> to make as well, or set it in your environment. Any remaining
> non-warning output from libtool (or warning output that shouldn't be
> warnings but notes) would be a bug you should report to bug-libtool.
> Thanks.
I hope the above will do as we the context is much clearer in this mail thread.
The install messages is over my head though.
>
>
> There is another angle in this story. Enter the silent-rules option.
> It currently allows to enable silencing of libtool (yes, silent-rules
> will pass --silent as flag to libtool), of most compile, and link rules.
> It doesn't address make install/uninstall rules yet. I don't mind going
> that way; the primary reason not more rules exploited a silent mode for
Great.
> 1.11 was that we didn't want to delay the release further, and that
> compile rules were what bothered users most. Most install rules aren't
> that verbose anyway.
>
> Patches to this end are welcome, under the usual side conditions:
> non-trivial patches need copyright assignment, all new behavior needs
> full testsuite exposure, and so on. I might work on this eventually.
>
> Thanks,
> Ralf
>
> PS: And yes, 1.11.2 without silent-rules mode will return to have the
> exact output from before 1.11 (without the ugly additional empty line),
> we got that small regression fixed now.
>
