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
