[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: silent installs

From: Joakim Tjernlund
Subject: Re: silent installs
Date: Sat, 30 Jan 2010 14:57:40 +0100

Ralf Wildenhues <address@hidden> 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 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 could change those line from func_warning
to func_verbose instead:

---   (revision 57662)
+++   (working copy)
@@ -2028,7 +2028,7 @@
            relink_command=`$ECHO "X$relink_command" | $Xsed -e 

-         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"'
@@ -2269,7 +2269,7 @@

     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

> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]