how to deal with system-specific build options reliably

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?

-- 
    /kinkie