[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: Fri, 29 Jan 2010 11:30:52 +0100

Ralf Corsepius <address@hidden> wrote on 2010/01/29 10:05:04:
> On 01/29/2010 09:35 AM, Joakim Tjernlund wrote:
> > Ralf Corsepius<address@hidden>  wrote on 2010/01/29 09:21:46:
> >
> >> On 01/29/2010 09:05 AM, Joakim Tjernlund wrote:
> >>
> >>> 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.
> >>>
> >> What for?
> >>
> > I just said that below.
> >
> Well, then I must be missing something.
> >>
> >>> When a developer asks for a silent build in order to catch problems
> >>> all one should see is real warnings and problems.
> >>>
> >> Silent make rules are harmful:
> >>
> >> E.g.
> >> - Bogus defines
> >> - Bogus include/library paths
> >> - Incorrect CFLAGS/...
> >> - link library order
> >> typically do not show up as compiler warnings or errors.
> >>
> > Not seeing any warnings at all because it drowns in hundreds
> > of status messages is an even bigger problem.
> >
> Simply create build logs and analyse them?

make -s is my tool. What is the value of having hundreds of
 /bin/sh ../../libtool --silent  --mode=install /usr/bin/install -c  ....
in your face when you are looking for problems?

To analyse logs with thousands lines one needs some tool
to find the interesting ones. How do you propose I do that?
If a writing complex tool is the answer then autotools
needs to provide that tool.

> >> when making silent make-rules the default, packages tend to gradually
> >> rott, because bugs tend to slip through unnoticed.
> >>
> > I doubt that, but that is besides the point.
> Believe me, you are in error. Just wait, you will sooner or later see
> this happen with any non-trivial package.
> There are many examples for this around.

When a user do use make -s and the screen is full
of install messages how does that help to find problems?

make -s is a effective way to find lots of problem(but not all)
so I would like to be able to use that. Other problems such
as link order needs a different approach.

Any non trivial package will have a ton of msgs in the log, the
problem is to find the msgs that might indicate a problem and
you don't have all day to zip through the whole log


reply via email to

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