Re: test-suite and OS specific options

On Wed, 28 Oct 2009 00:14:19 +0100, Henrik Nordstrom
<henrik_at_henriknordstrom.net> wrote:
> After the libcap change the testsuide now fails on CentOS, this time due
> to layer-02-maximus enablind linux-tproxy but as libcap isn't available
> it's not really enabled but still compiled. A little confusing, as far
> as I know I did not change the logics on when to enable what of Linux
> tproxy..
>
> So to the question, is it really sane that the test suite blindly
> enables OS specific options? I mean I would not expect the build to work
> if one uses --enable-linux-netfilter on an BSD box for example, or
> --enable-linux-tproxy2 on a box where Linux TPROXY2 is not available or
> alternatively with now required libcap missing..
>
> Regards
> Henrik

The options were and some continue to be a bit of a mess. Under maximus
the test bed enables all the ones known to not hard-fail for one reason or
another on any OS regardless of their name.

In the particular linux-tproxy2 case it is one of the many options that
auto-detect and quietly warn before disabling the feature and continuing
with the build. _even if configured explicitly_ (yeah nasty).

The TestBed is currently testing that either this quiet-fail behavior
works and prevents build, or the build works. Neither is permitted to fail.

What we see happening now on CentOS is the configure tests soft-failing
but the build happens anyway. Genuine breakage incorrectly causing
LINUX_TPROXY2 to be defined when missing stuff and get through to a broken
build situation.

PS. There is a planned level of 'maybe' which I have not yet got around to
adding. It will allow testing of hard-fail options in future and accept
certain explicit fail messages (ie "wrong OS type" or "dependencies
missing") as an okay pass result.
Until we can get that build level going properly I'm reluctant to
hard-fail things. Since we can't then test them regularly.

Amos
Received on Wed Oct 28 2009 - 01:24:31 MDT