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

2010-04-25 Thread Kinkie
>> It's probably time for another interim merge.
> +1

That's two votes. Merging.

-- 
/kinkie


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

2010-04-25 Thread Henrik Nordstrom
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?

2010-04-23 Thread Amos Jeffries

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?

2010-04-23 Thread Kinkie
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?

2010-04-22 Thread Amos Jeffries

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?

2010-04-22 Thread Kinkie
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