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

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:
>
>>   I've stumbled across a portability glitch in the build-test process:
>> The current semantics for --enable-* options are: --disable
>> force-disables, --enable force-enables and fails the build if needed
>> support stuff is missing, unspecified uses the option-specific default
>> (which in most cases is --enable), and auto-detects support.
>>
>> This is all fine options which are default-enabled, but not so much
>> for some (such as --enable-valgrind) which are not default-enabled: in
>> that case the only useful test-layer is the "maximus" one which
>> force-enables, and fails on those platforms where support headers are
>> not available (e.g. valgrind on solaris)
>>
>> Options are (in my personal order of preference, most to least)
>> 1. use some --enable switches conditionally in the layer build options
>
> #1 is fine with me, at least as a short-term solution but note that #1
> and #4 sound the same.

"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.

>
>> 3. remove from the testsuite those --enable-* options which are not
>> available on all platforms
>> 4. do not standardize how enable options are handled.

-- 
    /kinkie