Ralf Corsepius <rc040...@freenet.de> wrote on 2010/01/29 10:05:04: > > On 01/29/2010 09:35 AM, Joakim Tjernlund wrote: > > Ralf Corsepius<rc040...@freenet.de> 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 Jocke
