[Top][All Lists]

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

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

From: Ralf Corsepius
Subject: Re: `--prefix /foo' mishandled in sub-configure invocation
Date: 06 Nov 2001 11:54:15 +0100

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

>   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)


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

reply via email to

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