Re: RFC: how to handle OS-specific configure options?

Kinkie wrote:
> Hi all,
> as part of the configure-refactor work I'm currently reworking how
> the various firewalling frameworks are handled.
> In general, since the autoconf framework now correctly handles
> tristate (yes/no/auto) options, I'm inclined to adopt where sensible
> this general guideline: default should be "auto"
> (enable-if-available), and fail the configuration if the user
> force-enables something that can't be delivered.
>
> Two consequences: squid will build more stuff in (interception is for
> instance generally not included), and build-tests that force-enable
> will fail because firewalling frameworks are mutually exclusive, so
> more build tests will have to rely on the default "auto" approach.
>
> I'd like to collect feedback on this approach. Reverting those options
> to "do not build by default" is of course doable, even trivial.
>
> Thanks
>

In the current 3.HEAD the lookups are not mutually exclusive any more.
Run-time checking of the lookup results is done now with the intention
of doing your proposed change.

It seems to be that we can enable all and auto-disable firewalling
frameworks based on the headers and libraries available at build now
without major problems.

There is some potential difficulties between lookups where the success
results are indistinguishable from a fail results;
   IPF is currently broken. Will need a full code fix anyway.
   TPROXY has already been split at the run-time flag level.

NP: The non-Linux lookups still need somebody with knowledge of the
non-Linux OS NAT to test and fix the existing code. All we have is one
user testing IPF and reporting a lookup fail but no fix.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.1