Re: eCAP configure tests

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

Cheers,

Alex.
Received on Wed Oct 15 2008 - 02:00:28 MDT