Re: Site Macro Directory

[Akim Demaille]

>>>>> "Paul" == Paul Eggert <address@hidden> writes:

>> From: Akim Demaille <address@hidden> Date: 24 May 2002 12:35:53
>> +0200

>> | Every other tool that I know of that accepts a `-I' option
>> (including | gcc, GNU make, GNU m4, and perl) prepends the
>> arguments to the search | path in the order specified.  As a
>> result, I was extremely surprised | to discover that autoconf does
>> the reverse.
>> 
>> Because the logic is to respect the last flag occurrence first for
>> all the other flags but this one.  Honestly, to me it is a serious
>> bug in all the other implementations.

Paul> On this point I must agree with Mark D. Roth.  It is a serious
Paul> inconsistency if autoconf processes -I options backwards from
Paul> every other command in the universe.  (It is news to me that
Paul> Autoconf does this; otherwise I would have complained earlier.
Paul> :-)

It is so since autom4te.  If the problem is wrt -I, I'm fine with
renaming it -i.  Up to now, it is used only in exceptional cases,
i.e., as far as I know noone but Autoconf maintainers have used it.


Paul> POSIX does not specify Autoconf, but POSIX does specify utility
Paul> syntax guidelines that Autoconf should follow unless there's a
Paul> good reason otherwise.  You can find them at this URL:

Paul> 
http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap12.html#tag_12_02

Paul> Autoconf's treatment of -I seems to violate Guideline 11, which
Paul> reads as follows:

Paul>    The order of different options relative to one another should
Paul> not matter, unless the options are documented as
Paul> mutually-exclusive and such an option is documented to override
Paul> any incompatible options preceding it. If an option that has
Paul> option-arguments is repeated, the option and option-argument
Paul> combinations should be interpreted in the order specified on the
Paul> command line.

Paul> I understand that there is a good argument for doing it
Paul> backwards, but in my view it is outweighed by the confusion this
Paul> engenders, and by the lack of conformance to the standard.  cc,
Paul> perl, etc are not going to change to Autoconf's viewpoint, and
Paul> it's better for everybody concerned if we fall into line on this
Paul> issue.

I feel sad wrt issue.  It's all wrong.  It prevents the use of aliases
which include -I that you override with options and all sort of things
I regularly use :(  It requires at least two internal variables to
maintain the library path, and therefore a more complex behavior :(