Re: eCAP configure tests

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 15 Oct 2008 16:25:05 +1300

Alex Rousskov wrote:
> On Wed, 2008-10-15 at 14:15 +1300, Amos Jeffries wrote:
>
>>> IMO, if a user explicitly requested feature Foo and Foo cannot be
>>> supported, we should fail rather than ignore the user request.
>> That would not be a good idea either IMO. Rather have eCAP default on and
>> self-disable noisily on missing dependencies. Which would be a nasty big
>> shock and hassle to most users.
>
> Sorry, I am not sure which bad idea or nasty shock you are referring to.
> If the user explicitly requested feature Foo, Foo cannot be supported,
> and ./configure fails, I do not think there will be any shock or, at
> least, the shock over missing dependencies would be a good thing :-).

I was referring to silently turning it on (default on) then being noisy
when things fail.
We should not default-on any feature that has non-common dependencies.
Or if we do (thinking po2html etc) we should not be noisy at people when
it fails, cause it will.

>
>> I'm starting to think it might be better to alter the testing methods to
>> make it smarter to look at how to incorporate such fatal failures.
>>
>> The currently it just runs a preset collection of configure optiona and
>> build flags. greps and report lines with "error:" and "WARNING" etc
>> output. But fully abort and prevent remaining test runs when an exit(1) is
>> encountered.
>>
>> I think I can make it catch exit(1) and treat specific failure lines as
>> soft errors. We will need to con-ordinate a unique signature for those
>> lines though. A unique error message prefix ie "MISTAKE:"
>
> You can have a list of expected/bypassable failures for a given
> environment, but I think it would be better to have a list of
> correct ./configure options for a given environment.

I was thinking not so much for an environment as a global ignore list
shared for all environments.
And warned, but non-fatal if one on the list fails with a known specific
fail state. Unknown fail states (ie in unit-tests) are still handled as
total failure.

Amos

-- 
Please use Squid 2.7.STABLE4 or 3.0.STABLE9
Received on Wed Oct 15 2008 - 03:25:10 MDT

This archive was generated by hypermail 2.2.0 : Wed Oct 15 2008 - 12:00:05 MDT