bug-automake
[Top][All Lists]
Advanced

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

bug#7434: When an incorrect option is used before --help/--version, auto


From: Stefano Lattarini
Subject: bug#7434: When an incorrect option is used before --help/--version, automake behaviour is inconsistent with that of other GNU programs.
Date: Sun, 28 Nov 2010 19:30:03 +0100
User-agent: KMail/1.13.3 (Linux/2.6.30-2-686; KDE/4.4.4; i686; ; )

On Sunday 28 November 2010, Ralf Wildenhues wrote:
> * Stefano Lattarini wrote on Fri, Nov 26, 2010 at 06:41:20PM CET:
> > > Besides, in the particular case of automake, how often do automake
> > > or aclocal get invoked directly?  To my experience, they are almost
> > > always invoked by autoreconf, ./bootstrap, or some custom autogen.sh
> > > script.
> 
> (aside: autoreconf works just in the same way as automake in this
> respect.)
> 
> > > > > Let's address this on bug-standards before changing any programs.
> > >
> > Now a decision has been reached on bug-standards *not* to tighten the
> > specification about the behaviour of --help and --version:
> >  <http://lists.gnu.org/archive/html/bug-standards/2010-11/msg00010.html>
> 
> Nor to forbid the current behavior of automake.
>
True, but as I said before I never considered the automake behaviour to
be wrong or not GCS-compliant, just (IMO uselessly) overzealous.
 
> > Considering that, do you agree to simplify the automake/aclocal option
> > parsing by not trying to process --help/--version options encountered
> > after invalid options?
> 
> I'm painfully aware that this is a near-bikeshed discussion, but I
> simply fail to see the advantage of taking away existing functionality
> helpful for the user, even if only a few users.
>
The point is that IMO such functionality is in fact not helpful for any
user.  But since this claim of mine lacks explicit evidence and is not
backed up by quantitative data ATM, I'll have to accept your decision.

> Code simplification is
> nice, but this change wouldn't suddenly make automake fast, all that
> much more readable, or anything similar.  Barring that there is a
> technical advantage for our users[1],
>
I don't think there is, unfortunately.

> I remain unconvinced.
> 
> Sorry,
> Ralf
> 

Regards,
   Stefano





reply via email to

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