Re: eCAP configure tests

> On Tue, 2008-10-14 at 22:06 +1300, Amos Jeffries wrote:
>
>> On the eCAP side. I've found an issue with its configure tests. Seems to
>> me that the MSG_ERROR and MSG_FATAL are the wrong way around.
>
> I did not find MSG_FATAL in autoconf documentation. The code is using
> AC_MSG_ERROR and AC_MSG_FAILURE, both of which are "fatal" to the
> configure process.
>
>> Should be:
>> * FATAL if ecap listed with explicit disable-loadable
>
> The code is using AC_MSG_ERROR, which is fatal. I think it is the right
> macro to use when explicit configure options contradict each other. Do
> you agree? If not, what macro would you use?
>
>> * ERROR with failover to disable, if ecap listed but libraries missing.
>
> The code is using AC_MSG_FAILURE, which is an AC_MSG_ERROR wrapper. Are
> you suggesting that we use AC_MSG_WARN and implicitly disable eCAP
> support that the user has explicitly enabled?

Ah, okay. I only hit one of the two and reading the configure.in code its
easy to mistake one for fatal and the other not. If they are both fatal
thats okay.

>
>> Without a sane failover we can't do portable permutation testing of the
>> ecap code asent libecap. The existing testbed does not handle fatal exit
>> cases yet.
>
> What is "portable permutation testing"?

The ./test-builds.sh script. Being able to run and pass all tests on any
OS squid can build on.
As it stands, we can't include eCAP in the default sets of tests.

>
> Would Kinkie's suggestion to implicitly enable eCAP if there is libecap
> installed solve the problem? I may prefer that because it does not
> override explicit user configuration and because many, if not most,
> users pay little attention to ./configure warnings.

That would be the other way.

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

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:"

Amos
Received on Wed Oct 15 2008 - 01:15:36 MDT