silent-rules (was: checking automake version in configure.ac)

[Ralf Wildenhues]

[ adding automake@ ]

Hello Ralf,

* Ralf Corsepius wrote on Tue, Oct 06, 2009 at 05:49:52PM CEST:
> a) AM_SILENT_RULES are harmful (I know, you know that I think about
> this (mal-) "feature" this way - Working around the issues they are
> causing in Fedora packaging is a major nuissance.)

Could you expand on this nuisance a bit more?

What work does it cause except for using --disable-silent-rules at
configure time or V=1 at make time?  This is an honest question;
I'd like to avoid extra work for distributors.

Thanks,
Ralf

[Ralf Corsepius]

On 10/06/2009 09:52 PM, Ralf Wildenhues wrote:

> [ adding automake@ ]
>
> Hello Ralf,
>
> * Ralf Corsepius wrote on Tue, Oct 06, 2009 at 05:49:52PM CEST:
>> a) AM_SILENT_RULES are harmful (I know, you know that I think about
>> this (mal-) "feature" this way - Working around the issues they are
>> causing in Fedora packaging is a major nuissance.)
>
> Could you expand on this nuisance a bit more?

I did so several times before.

Anyway, ...

The problem is verifying "correctness of building" packages in batches.

i.e. to monitor/inspect CFLAGS, CPPFLAGS, LDFLAGS etc. in compiler calls
etc. for correctness

(NB: A package, which compiles without warning doesn't mean it is being
built correctly.)

> What work does it cause except for using --disable-silent-rules at
> configure time or V=1 at make time?
Exactly this is the problem.

It means automake is pushing around package maintainers to modify their
packages to automake's behavioral changes.

As many package maintainers are no autotools' specialists, this is a
non-trivial problem.

Ralf

[Bob Friesenhahn]

On Tue, 13 Oct 2009, Ralf Corsepius wrote:

>
> The problem is verifying "correctness of building" packages in batches.
>
> i.e. to monitor/inspect CFLAGS, CPPFLAGS, LDFLAGS etc. in compiler calls etc.
> for correctness
>
> (NB: A package, which compiles without warning doesn't mean it is being built
> correctly.)
>
>> What work does it cause except for using --disable-silent-rules at
>> configure time or V=1 at make time?
> Exactly this is the problem.

The problem isn't the support for silent rules.  The problem is that
some packages are enabling it by default because it looks like Linux
and Linux is cool.  This is exactly the problem that I was concerned
about and why I fought to ensure that it is not enabled by default.
Unfortunately, it was made very easy for a package author to enable by
default and some package authors are now doing so even though it makes
open source software seem confusing and inconsistent.

> It means automake is pushing around package maintainers to modify their
> packages to automake's behavioral changes.

Quite annoying indeed.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

[Ralf Corsepius]

On 10/13/2009 04:49 PM, Bob Friesenhahn wrote:

> On Tue, 13 Oct 2009, Ralf Corsepius wrote:
>>
>> The problem is verifying "correctness of building" packages in batches.
>>
>> i.e. to monitor/inspect CFLAGS, CPPFLAGS, LDFLAGS etc. in compiler
>> calls etc. for correctness
>>
>> (NB: A package, which compiles without warning doesn't mean it is
>> being built correctly.)
>>
>>> What work does it cause except for using --disable-silent-rules at
>>> configure time or V=1 at make time?
>> Exactly this is the problem.
>
> The problem isn't the support for silent rules.  The problem is that
> some packages are enabling it by default

Indeed. What makes the situation worse is some upstreams shipping
"common" aclocal-macros which enable it by default. This cause quite
some amount of surprises when analysing buildlogs of packages which for
whatever reasons run autoreconf/autogen.sh.

> because it looks like Linux and Linux is cool.
:=)

Ralf

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Corsepius on 10/13/2009 9:20 AM:
>>>> What work does it cause except for using --disable-silent-rules at
>>>> configure time or V=1 at make time?
>>> Exactly this is the problem.
>>
>> The problem isn't the support for silent rules.  The problem is that
>> some packages are enabling it by default

But YOU can still disable it by default, by writing your packaging
automation tools to supply --disable-silent-rules as part of calling
./configure, and/or writing an appropriate config.site.  In other words,
the person running ./configure STILL has the option to choose YOUR desired
default, even if it is different than the package author's desired
default.  The use of silent-rules is an option, not a mandate.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrVIjoACgkQ84KuGfSFAYBm1ACbB9ySznASW/iwTtoWtJKHjqzW
gTsAnjr5gWKg/ZwTOZCjUKZYUiS9A4jI
=hAug
-----END PGP SIGNATURE-----

[Ralf Corsepius]

On 10/14/2009 02:58 AM, Eric Blake wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to Ralf Corsepius on 10/13/2009 9:20 AM:
>>>>> What work does it cause except for using --disable-silent-rules at
>>>>> configure time or V=1 at make time?
>>>> Exactly this is the problem.
>>>
>>> The problem isn't the support for silent rules.  The problem is that
>>> some packages are enabling it by default
>
> But YOU can still disable it by default, by writing your packaging
> automation tools to supply --disable-silent-rules as part of calling
> ./configure, and/or writing an appropriate config.site.  In other words,
> the person running ./configure STILL has the option to choose YOUR desired
> default, even if it is different than the package author's desired
> default.

Exactly what I said in a previous mail: Automake is pushing around
package maintainers to modify their packages to automake's behavioral
changes. (Here package maintainer == Package installers)

 > The use of silent-rules is an option, not a mandate.
IMO, upstream maintainers, who use silent rules, don't have much clues
about what they are doing - Their practice is harmful.

[Ralf Wildenhues]

[ dropping autoconf@ ]

* Ralf Corsepius wrote on Tue, Oct 13, 2009 at 05:20:30PM CEST:

> On 10/13/2009 04:49 PM, Bob Friesenhahn wrote:
> >On Tue, 13 Oct 2009, Ralf Corsepius wrote:
> >>
> >>The problem is verifying "correctness of building" packages in batches.
> >>
> >>i.e. to monitor/inspect CFLAGS, CPPFLAGS, LDFLAGS etc. in
> >>compiler calls etc. for correctness
> >>
> >>(NB: A package, which compiles without warning doesn't mean it
> >>is being built correctly.)
> >>
> >>>What work does it cause except for using --disable-silent-rules at
> >>>configure time or V=1 at make time?
> >>Exactly this is the problem.

I still fail to understand.  What problem do you have with either
  echo export V=1 >> ~/.bashrc

or
  echo enable_silent_rules=no >> ${CONFIG_SITE-/usr/local/share/config.site}

once on your distro build daemon and be done with it?

This is still a serious question, and I haven't seen anything in your
replies that answers it.  Yes, it may be pushing around distro
maintainers, but it's more of a gentle nudge than anything else if you
ask me.

Or is it that you need to teach bug reporters to do this?

Complaining alone won't change the situation, unless we also find ways
to improve things.  Going back isn't an option, for several reasons,
so let's see how to best go forward.

> >The problem isn't the support for silent rules.  The problem is
> >that some packages are enabling it by default
> Indeed. What makes the situation worse is some upstreams shipping
> "common" aclocal-macros which enable it by default. This cause quite
> some amount of surprises when analysing buildlogs of packages which
> for whatever reasons run autoreconf/autogen.sh.

Well, isn't that worthy of a bug report to that upstream then?

Thanks,
Ralf

[Ralf Corsepius-3]

On 10/14/2009 07:05 AM, Ralf Wildenhues wrote:

> [ dropping autoconf@ ]
>
> * Ralf Corsepius wrote on Tue, Oct 13, 2009 at 05:20:30PM CEST:
>> On 10/13/2009 04:49 PM, Bob Friesenhahn wrote:
>>> On Tue, 13 Oct 2009, Ralf Corsepius wrote:
>>>>
>>>> The problem is verifying "correctness of building" packages in batches.
>>>>
>>>> i.e. to monitor/inspect CFLAGS, CPPFLAGS, LDFLAGS etc. in
>>>> compiler calls etc. for correctness
>>>>
>>>> (NB: A package, which compiles without warning doesn't mean it
>>>> is being built correctly.)
>>>>
>>>>> What work does it cause except for using --disable-silent-rules at
>>>>> configure time or V=1 at make time?
>>>> Exactly this is the problem.
>
> I still fail to understand.  What problem do you have with either
>    echo export V=1>>  ~/.bashrc
>
> or
>    echo enable_silent_rules=no>>  ${CONFIG_SITE-/usr/local/share/config.site}
>
> once on your distro build daemon and be done with it?

OK, I realize you don't have much clues about building rpms.

Wrt. question: Nope, this is not possible, because V is a much too
general variable name to set it globally.
The likelihood it will clash with another V amongst the 1000s of
packages Fedora consists of is simply too high.

automake should have used a name-space guarded variable, instead or not
be using any variable at all but be relying on a configure-time option
(--enable-verbose or similar) only.

> This is still a serious question, and I haven't seen anything in your
> replies that answers it.  Yes, it may be pushing around distro
> maintainers, but it's more of a gentle nudge than anything else if you
> ask me.

> Or is it that you need to teach bug reporters to do this?
That's what we currently are doing:

You (automake) have pushed us around to tell them:
"Add V=1" to prevent automake from producing it's silent build.logs.

I guess, I don't have to emphasize that this fuels the already very
vocal community which is agitating against automake.

> Complaining alone won't change the situation, unless we also find ways
> to improve things.  Going back isn't an option, for several reasons,
> so let's see how to best go forward.
IMO, removing AM_SILENT is the only option. It's poorly implemented
("V") kid-stuff too cater people who have little clues about the
pitfalls of building.

>>> The problem isn't the support for silent rules.  The problem is
>>> that some packages are enabling it by default
>> Indeed. What makes the situation worse is some upstreams shipping
>> "common" aclocal-macros which enable it by default. This cause quite
>> some amount of surprises when analysing buildlogs of packages which
>> for whatever reasons run autoreconf/autogen.sh.
>
> Well, isn't that worthy of a bug report to that upstream then?
Well, people doing so are from the club of "people having little clues"
about the pitfalls lurking in building.

IMO, you should remove AM_SILENT from automake and the case will be closed.

Ralf

[Bob Friesenhahn]

On Wed, 14 Oct 2009, Ralf Wildenhues wrote:

>>>>> What work does it cause except for using --disable-silent-rules at
>>>>> configure time or V=1 at make time?
>>>> Exactly this is the problem.
>
> I still fail to understand.  What problem do you have with either
>  echo export V=1 >> ~/.bashrc
>
> or
>  echo enable_silent_rules=no >> ${CONFIG_SITE-/usr/local/share/config.site}
>
> once on your distro build daemon and be done with it?
>
> This is still a serious question, and I haven't seen anything in
> your replies that answers it.  Yes, it may be pushing around distro
> maintainers, but it's more of a gentle nudge than anything else if
> you ask me.

It is interesting that Ralf Corsepius is encountering issues with
building distribution RPMs since building distribution RPMs is done in
a very well managed and controlled environment.  Sometimes it is done
in a chrooted environment, or in a virtual machine created just for
that task.  Care is taken to ensure that user and customized system
environments are not part of the build equation.  The situation is far
less constrained for source-based operating environments such as
Gentoo and FreeBSD Ports, and definitely for end users who manually
download, configure, and build.  FreeBSD Ports has over 20K packages
to worry about now and port maintainers are not always as active as
they need to be.

> Complaining alone won't change the situation, unless we also find
> ways to improve things.  Going back isn't an option, for several
> reasons, so let's see how to best go forward.

Actually, complaining can indeed change the situation.  I encourage
anyone and everyone to complain stridently to whoever is making the
decision to enable silent build by default (which is a very selfish
sort of decision).  With enough back-pressure from the masses, this
simple boolean can be toggled to the legacy default used since the
dawn of GNU.  Open source is for users and the users have a right to
complain to developers and maintainers.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

[Ralf Wildenhues]

* Ralf Corsepius wrote on Wed, Oct 14, 2009 at 09:23:10AM CEST:
> On 10/14/2009 07:05 AM, Ralf Wildenhues wrote:
> >
> >I still fail to understand.  What problem do you have with either
> >   echo export V=1>>  ~/.bashrc
> >
> >or
> >   echo enable_silent_rules=no>>  ${CONFIG_SITE-/usr/local/share/config.site}

> Wrt. question: Nope, this is not possible, because V is a much too
> general variable name to set it globally.

What about the other approach then?

> The likelihood it will clash with another V amongst the 1000s of
> packages Fedora consists of is simply too high.

Have you tried or are you guessing?

> automake should have used a name-space guarded variable, instead or
> not be using any variable at all but be relying on a configure-time
> option (--enable-verbose or similar) only.

But it *is* relying on a configure-time option.  Point is, developers
can override those in their configure.ac script, or default them in a
different way than we do, even if they shouldn't.  This isn't new, this
has always been the case with Autoconf-generated configure scripts.

Thanks,
Ralf

[Ralf Corsepius]

On 10/14/2009 06:55 PM, Bob Friesenhahn wrote:
> On Wed, 14 Oct 2009, Ralf Wildenhues wrote:
>
Actually, complaining can indeed change the situation.

Exactly.

To put it bluntly, I find the situation automake as shifted itself to be
similar to this ole' joke:

"Look Ma, I can ride my bike with the hands off the handlebar" ... some
hours later, the same kid will tell: "Look Ma, I can ride my bike
without teeth".

In other words, I am expecting the same users who find "AM_SILENT"
"cool", to be loosing their teeth some time later in some violent accidents.


Ralf

[Yavor Doganov-3]

В Thu, 15 Oct 2009 09:18:54 +0200, Ralf Corsepius написа:

> In other words, I am expecting the same users who find "AM_SILENT"
> "cool", to be loosing their teeth some time later in some violent
> accidents.

As a distro package maintainer and a user I am with you on this matter,
but you should not blame the Automake developers for implementing this
feature.  Clearly, there are people who like it, so what is the problem?

I agree that distro builds should be as verbose as possible.  In fact in
Debian we caught some severe bugs by enabling verbose builds for GNUstep
packages, and we were badly bitten when there were incompatible changes
(gnustep-make 1.x -> 2.x) a few years ago that were *hidden* by the
silent output.

So, what's the problem for you to pass --disable-silent-rules,
--disable-shave, messages=yes, etc?  I do it for all my packages that
have silent rules by default, and the build logs are as verbose as I'd
like them to be:

https://buildd.debian.org/~luk/status/package.php?p=kazehakase

[Bob Friesenhahn]

On Thu, 15 Oct 2009, Ralf Corsepius wrote:
>
> "Look Ma, I can ride my bike with the hands off the handlebar" ... some hours
> later, the same kid will tell: "Look Ma, I can ride my bike without teeth".
>
> In other words, I am expecting the same users who find "AM_SILENT" "cool", to
> be loosing their teeth some time later in some violent accidents.

My own package supports silent builds but it is not enabled by default
because I believe that silent builds are intended for the package
developer (who repeatedly builds the software hundreds or thousands of
times in the same directory on the same system with the same options)
and not for other people who build the package just once in a
different environment.  I enable silent mode for my own builds because
failures in my builds are almost always due to something I got wrong
in the code, and not related to build options or the system.  This is
why I consider silent mode to be "selfish".

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

[Richard Ash-6]

On Wed, 2009-10-14 at 03:17 +0200, Ralf Corsepius wrote:

> > But YOU can still disable it by default, by writing your packaging
> > automation tools to supply --disable-silent-rules as part of calling
> > ./configure, and/or writing an appropriate config.site.  In other words,
> > the person running ./configure STILL has the option to choose YOUR desired
> > default, even if it is different than the package author's desired
> > default.
>
> Exactly what I said in a previous mail: Automake is pushing around
> package maintainers to modify their packages to automake's behavioral
> changes. (Here package maintainer == Package installers)

Or use the config.site mechanism as part of the build environment, which
means no change to the packaging automation tools, just an addition to
the build environment (which I assume you have to standardise anyway).

Richard