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

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.

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

Amos
Received on Tue Jul 06 2010 - 23:08:52 MDT