Re: how to deal with system-specific build options reliably

On 07/06/2010 01:26 PM, Kinkie wrote:
> On Tue, Jul 6, 2010 at 8:48 PM, Alex Rousskov
> <rousskov_at_measurement-factory.com> wrote:
>> On 07/06/2010 09:52 AM, Kinkie wrote:

> "auto" (or --enable switch unspecified) mostly means "try to enable".
> The help-text should give a hint if it is default-enable (help text
> shows the --disable style option) or default-disable (the help text
> shows the --enable style option).
> Notice that for already refactored switches, --enable-foo=yes,
> --enable-foo=true, and --enable-foo are synonims, as are
> --enable-foo=no, --enable-foo=false, and --disable-foo
>
>>> 2. add a fourth switch to --enable options: which would then be
>>> --enable-foo={yes,no,auto,maybe} ("maybe" meaning: enable if
>>> default-disabled, but skip if support isn't available)
>> I assume we already have "auto". Can we make "auto" do what the proposed
>> "maybe" does? Where is the current "auto" behavior needed where the
>> proposed "maybe" behavior does not work?
>
> The difference is that "auto" would leave the default setting to the
> specific option, while "maybe" would always try to enable, disable if
> building is not possible.

Understood.

IMHO, the decision tree sounds too complex, given the m4 syntax we need
to implement all these decision flavors with. Perhaps it is better to
leave that complexity out of configure.in and move it to specialized
scripts that can be written in more appropriate languages (or at least
simplify by explicitly listing the right options for a given
environment)? No strong opinion.

How do others solve this problem?

Alex.
Received on Tue Jul 06 2010 - 20:10:57 MDT