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

On 07/07/2010 12:28 AM, Kinkie wrote:
> 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.

IMHO, the above switch statement (or something similar), located in some
test script, would be better than adding "maybe" to ./configure options.

Alex.

>> --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.
>
Received on Wed Jul 07 2010 - 16:04:55 MDT