>>>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
>> From: Akim Demaille <[EMAIL PROTECTED]> 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 :(
