[Top][All Lists]

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

Re: silent build rules

From: John Calcote
Subject: Re: silent build rules
Date: Wed, 01 Apr 2009 14:08:33 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2

While we're on the issue of Automake silent rules, I've got a comment about Libtool hiding half of it's compiles.(Thus, I've added the libtool list as well.)

I was recently building a project that failed without an error message, while running under "non-silent" mode, or the original GNU build noise level. This puzzled me to no end until I realized that the error was occurring in one of the two (pic/non-pic) compiles that libtool shuffles off to /dev/null. The error was regarding global labels found in in-line assembly, that -fPIC builds didn't like. But the -fPIC builds were silenced.

Is there any command-line option for configure and/or make that will keep libtool from hiding half the compiles? (Odd that I, of all people, should ask for this, since I was one of the original proponents of silent builds!)



On 4/1/2009 1:32 PM, Bob Friesenhahn wrote:
On Wed, 1 Apr 2009, Ralf Wildenhues wrote:

* Eric Blake wrote on Wed, Apr 01, 2009 at 08:52:36PM CEST:
According to Bob Friesenhahn on 4/1/2009 12:40 PM:

It seems that I will need to permanently define and export the arbitrary
variable 'V' in my shell environment in order to avoid confusion later
since I won't know how a build will behave until I type 'make'.  That
leaves 25 more single-letter variables for my own use.

The rationale for keeping V was that users accustomed to the Linux build
system would not have to relearn.  Maybe that is not such a good
rationale: those who build the kernel regularly are hardly the least
experienced users.

More significantly, GNU users are not restricted to the Linux kernel or having any Linux experience at all. What feels normal for a Linux user may be bizarre for a non-Linux user.

My opinion is that if this mode is optional that it should default to "off" and that an action taken by the user (dot file, environment variable, configure option) to declare a personal preference can be used to trigger the Linux mode. Perhaps additional build modes would be contributed in the future.

Hopefully it won't alter the behavior of other scripts or builds.

As I wrote off-list already, unless you use the 'silent-rules' option
for your packages, your code should be built as always.

This new m4 release is the first package I have seen with this automake "Linux mode". I checked it for a special automake option and did not find it so I assume that it was provided when m4 was manually bootstrapped.

the default verbosity level that they are comfortable with.  Something
like './configure --disable-silent-rules' to request the V=1 behavior?

It is wrong to change the default from the convention used by GNU packages for at least 20 years. GNU packages should all build the same by default. This year's package should build similar (by default) to last-year's package.

Users of complex packages like my own would suffer severely if they build in Linux mode by default. Users of simple stand-alone packages like 'm4' are unlikely to suffer.

This is an open problem, and mentioned here:
Suggestions welcome.

A configure flag to set the user-preferred default is reasonable, as long as the default is the traditional "GNU" mode.

Bob Friesenhahn
GraphicsMagick Maintainer,

reply via email to

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