Re: RFC: how to handle OS-specific configure options?
>> It's probably time for another interim merge. > +1 That's two votes. Merging. -- /kinkie
Re: RFC: how to handle OS-specific configure options?
fre 2010-04-23 klockan 16:41 +0200 skrev Kinkie: > > It's probably time for another interim merge. +1
Re: RFC: how to handle OS-specific configure options?
Kinkie wrote:
On Fri, Apr 23, 2010 at 2:11 AM, Amos Jeffries wrote:
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.
Implemented.
I've also gone ahead with the auth configure changes we talked about:
five commands;
--disable-auth
(sets the USE_AUTH) preprocessor macro to 1 (default) or 0.
Default-disables all auth code, modules etc.
--disable-auth-{basic,ntlm,digest,negotiate}
--enable-auth-{basic,ntlm,digest,negotiate}="helper helper.."
--enable-auth-{basic,ntlm,digest,negotiate} (default) builds all
buildable helpers
--enable-auth-{basic,ntlm,digest,negotiate}=none enables auth scheme
but builds no helper
--disable-auth together with any --enable-auth-* will FAIL the configure.
It's probably time for another interim merge.
Wonderful.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.1
Re: RFC: how to handle OS-specific configure options?
On Fri, Apr 23, 2010 at 2:11 AM, Amos Jeffries wrote:
> 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.
Implemented.
I've also gone ahead with the auth configure changes we talked about:
five commands;
--disable-auth
(sets the USE_AUTH) preprocessor macro to 1 (default) or 0.
Default-disables all auth code, modules etc.
--disable-auth-{basic,ntlm,digest,negotiate}
--enable-auth-{basic,ntlm,digest,negotiate}="helper helper.."
--enable-auth-{basic,ntlm,digest,negotiate} (default) builds all
buildable helpers
--enable-auth-{basic,ntlm,digest,negotiate}=none enables auth scheme
but builds no helper
--disable-auth together with any --enable-auth-* will FAIL the configure.
It's probably time for another interim merge.
--
/kinkie
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
RFC: how to handle OS-specific configure options?
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 -- /kinkie
