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.
