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

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.

> 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?

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

Thank you,

Alex.
Received on Tue Jul 06 2010 - 18:49:53 MDT