> 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. On this point I must agree with Mark D. Roth. It is a serious inconsistency if autoconf processes -I options backwards from every other command in the universe. (It is news to me that Autoconf does this; otherwise I would have complained earlier. :-) POSIX does not specify Autoconf, but POSIX does specify utility syntax guidelines that Autoconf should follow unless there's a good reason otherwise. You can find them at this URL: http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap12.html#tag_12_02 Autoconf's treatment of -I seems to violate Guideline 11, which reads as follows: The order of different options relative to one another should not matter, unless the options are documented as mutually-exclusive and such an option is documented to override any incompatible options preceding it. If an option that has option-arguments is repeated, the option and option-argument combinations should be interpreted in the order specified on the command line. I understand that there is a good argument for doing it backwards, but in my view it is outweighed by the confusion this engenders, and by the lack of conformance to the standard. cc, perl, etc are not going to change to Autoconf's viewpoint, and it's better for everybody concerned if we fall into line on this issue.