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

On Wed, Jul 7, 2010 at 1:08 AM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> On Tue, 6 Jul 2010 21:26:40 +0200, Kinkie <gkinkie_at_gmail.com> 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:
>>>
>>>>   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.
>>
>
> My understanding of "auto" was that in the past it auto-enabled when build
> was possible and auto-disabled if build was not possible. I don't see why
> that has inverted all of a sudden and needs to become two options just to
> stay the same.
>
> foo=auto as the default in configure.in being the above behaviour.

It didn't, probably I was not clear enough.
We're mixing two different issues here: one is how flags are handled,
and another is what should be the default for such flags.
How flags are handled is being made consistent: --enable-foo means
"force enable, fail the build if foo can't be enabled". --disable
means "force disable foo" and --enable-foo=auto means "try to enable
foo, disable it if it can't be built".
Then there's the matter of the default values. For most flags the
sensible defeault is "auto", and so not specifying the flag follows on
to the default and try-builds the feature.
But in some cases (I'll take valgrind as an example) "auto" is NOT the
sensible default, as enabling it performs two different
configurations: it looks for the valgrind headers and it changes the
memory allocator to be valgrind-friendly. Having it have "auto" type
semantics would mean that unless force-disabled, it would change the
allocator to the valgrind-friendly one on all platforms where valgrind
headers can be found; I doubt we want that.
More test-suite-related is a similar issue: how to test OS-specific
stuff (e.g. interception infrastrutcture)? force-enabling it would
always fail the max build-set, as these options are mutually
incompatible. The current solution is to expunge those options from
the max test-set, and rely on "auto"-style behaviour: those code-paths
are build-tested in the "default" set but not in "max".

What I'd essentially suggest as a solution is to change the maximum
build-set and exploit the fact that it is in fact a sourced
shell-script, and add a big switch statement to it similar to:

case `uname -s` in
  *linux*) os_opts="--enable-valgrind --enable-netfilter" ;;
   *freebsd*) os_opts="--enable-ipf" ;;
esac

etc.

> --enable-foo=auto passed from the user is useless, they may as well pass
> yes/no explicitly per their needs. Everyone downstream from us (distro
> maintainers and self builders) all have explicit info and control available
> about the installed environment(s).

Yes. "auto" is a mostly internal-state flag, signaling "try-build".
Although it could be specified by the user, its usefulness is almost
completely with being the default value - which can then be dealt
accordingly.
It allows to simplify and clarify the code structure for the configure
script, separating the code handling input from the code processing
dependency checks.

-- 
    /kinkie