On Wed, 28 Oct 2009 02:31:48 +0100, Henrik Nordstrom <[email protected]> wrote: > ons 2009-10-28 klockan 14:24 +1300 skrev Amos Jeffries: > >> 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). > > Ugh.. and quite obviously the disable does not work properly.. > > I'll give it a stab tomorrow. > >> 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. > > What about making TPROXY, netfilter etc default enabled if found > available?
+1. I think the new NatLookup multi-plexing code is ready for mainstream, but its not exactly widely tested yet. > > Makes the minimum test have lots of --disable-xxx and --without-xxx, and > the maximus test is basically no configure options at all I guess except > for experimental features. Yes. If we can keep up the nesting of dependencies under feature enable wrappers the --without can be omitted in the presence of a --disable. Which keeps it slightly simpler. > > and to guarantee proper coverage over time, maybe have some nodes > running tests with specific --enable-xxx and --with-xxx options, making > the build fail on those hosts if the requirements have gone missing for > some reason.. The "maybe" and "nodeps" layers should take care of that part when done. Amos
