Re: `--prefix /foo' mishandled in sub-configure invocation

[Ralf Corsepius]

Am Mon, 2001-11-05 um 19.36 schrieb Alexandre Duret-Lutz:
> >>> "Ralf" == Ralf Corsepius <address@hidden> writes:
> 
> [...]
> 
>  Ralf> Well, supporting "--prefix foo" is a _bug_, IMO, because it is an
>  Ralf> exception from the rules (Why isn't --includedir foo supported?).
> 
>  Ralf> Furthermore it renders parsing command lines error-prone (The problem
>  Ralf> you have encountered is the proof of this statement) and more
>  Ralf> complicated than necessary.
> 
> Ralf, aren't you a little unfair today?  
Sorry, if this impression came over. It has definitely never been my
intension. 

>   1) `--includedir foo' is supported, as are all other options
Just for clarification: Are you saying that
--*dir foo 
--[with|without]* foo
--[enable|disable]* foo
all are supported? At least, I have not been aware of this.

IMO, allowing "--prefix foo" "--exec-prefix foo" etc. renders parsing
configure arguments basically more difficult, because it renders the
configure argument syntax context-sensitive.

Therefore, this considering '--prefix foo' in argument parsing results
into basically different requirements on parsers [1] and therefore must
be documented (or officially deprecicated), IMHO.


>   2) that was just a copy'n'paste error, nothing terrific
>   3) the handling of space separated option arguments in
>      configure looks very straightforward
> 
> Besides, my equal key is broken, this character is missing from
> the X fonts I have installed, and my little finger is set in
> plaster. ;o)
;)

Ralf

[1] I am referring to argument parsers in user-written portions of
configure.acs, not to autoconf/automake-generated parsers/parse
fragments.