In message <[EMAIL PROTECTED]> (on 31 October 2004
20:55:47 -0500), [EMAIL PROTECTED] (Michael G Schwern) wrote:
>On Sun, Oct 31, 2004 at 08:26:54PM -0500, Ed Allen Smith wrote:
>> >That would be centralizing internal details about individual modules,
>> >things that can change with every new version.
>>
>> I had in mind centralizing it, as such, only in a way that could be
>> automatically constructed, if at all possible.
>
>I don't think it can be usefully automated.
>
>Consider this simple sort of problem.
>
> if( eval { require Some::Module } ) {
> * one version of the code *
> }
> else {
> * some other version *
> }
>
>The code still works fine even without the module in question being there.
Umm... is this likely to be tested for with a core module? And if
testing for a core module is present, then the library module doing so would
appear to be prepared for said core module not being present. That
admittedly mainly says "default to assuming not required if uncertain".
>> >The checks for unbuilt core modules are a special case that CPAN modules
>> >and authors don't normally have to do.
>>
>> True. Perhaps something like the above should instead be part of
>> Test::Smoke, and the build process should simply have an option of "read
>> this file for tests to skip", which could have uses in other circumstances?
>
>No, you do not want Test::Smoke behaving differently from 'make test'.
Urr... yes, wasn't thinking, sorry. It should be Test::Smoke using such a
file, or internal data, to know what test failures to not automatically
report as problematic, just as it now doesn't treat tests not confirmed by a
harnessed failure as being cause to send to P5P (if so configured).
-Allen
--
Allen Smith http://cesario.rutgers.edu/easmith/
February 1, 2003 Space Shuttle Columbia
Ad Astra Per Aspera To The Stars Through Asperity
