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

On Tue, 6 Jul 2010 17:52:25 +0200, Kinkie <gkinkie_at_gmail.com> wrote:
> Hi all,
> 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
> 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)
> 3. remove from the testsuite those --enable-* options which are not
> available on all platforms
> 4. do not standardize how enable options are handled.
>
> Opinions?

The initial intention for the test-suite was to have a layer of
maybe-fails. Which ran each of those options, and ignored the failure if a
specific error message was output by configure. If that message was not
present its a real failure.

It's not done yet because I was still looking for a way to do it without
conflating the test runs.

Either way those options should not be tested in maximus if they are known
to legitimately fail under our standard usage.

Amos
Received on Tue Jul 06 2010 - 22:55:08 MDT