Re: eCAP configure tests

On Wed, 2008-10-15 at 16:25 +1300, Amos Jeffries wrote:
> 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.

Ah, in the above context, I was talking about an explicit request to
enable Foo.

> 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.

The only "default" suggestion on the table is Kinkie's idea to enable
eCAP if libecap is available and no explicit eCAP instructions were
given by the user. With this idea, ./configure will succeed. The build
may still fail if libecap is not installed correctly or if the
environment is not compatible with Squid eCAP code.

Given all the trade-offs, do you think we should enable eCAP if libecap
is available and the user was not explicit about eCAP status?

> 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.

I am OK with the "features known to fail often" list as long as it does
not hurt the error messages produced by those features. I would not
require adding a MISTAKE keyword or similar. Enumerating known failure
strings or patterns would be better, IMO.

Thank you,

Alex.
Received on Wed Oct 15 2008 - 05:49:47 MDT