2009/2/26 Michael G Schwern <[email protected]>:
> Rafael Garcia-Suarez wrote:
>> 2009/2/26 Michael G Schwern <[email protected]>:
>>> This is annoying and really its unnecessary.  The point of putting non-XS
>>> modules into ext/ is to reduce the differences between the CPAN and core
>>> versions.  This goes both ways.  The core is currently cheating in how it 
>>> runs
>>> ext/ tests, it's running them manually rather than using "make test".
>>>
>>> So I propose changing how the core runs the ext/ tests.  Rather than running
>>> them as part of one large run, let's take advantage of make and just let 
>>> "make
>>> test" cascade down into the ext/ directories.  The t/ and lib/ tests would 
>>> run
>>> first, then "make test" would be run in each ext/ directory.
>>>
>>> Thoughts?  I'm going to go hack on that.
>>
>> We have two test frameworks, t/TEST and t/harness.
>>
>> t/TEST is the simple one, for testing broken things. It has no
>> dependencies. Most notably, if Test::Harness is broken, t/TEST
>> still works. Your proposal implies that t/TEST goes away.
>
> t/TEST would still run the t/ and lib/ tests.  So all of the tests of core
> perl functionality are still run with t/TEST.  That's all left as is.
>
>
>> t/harness is the complex one, but requires Test::Harness to be
>> built and installed in lib/ properly. Your proposal implies
>> that it should be able to collate the results of many sub-runs
>> in each ext/ subdir. Is this handled already ? That doesn't sound
>> like a simple thing to do portably.
>
> Oh no, just using normal recursive make.
>
> test: perl-test ext-test
>
> ext-test:
>        cd ext/Attribute-Handlers && $(MAKE) test
>        cd ext/ExtUtils-MakeMaker && $(MAKE) test
>        cd ext/Errno && $(MAKE) test
>        ...and so on...
>
> Each test will show up to the user as an individual test run and result,
> rather than the huge block of tests we get now.  This is visually unappealing,
> and maybe we can do something to make it a little nicer, but that's how
> recursive make works everywhere else including MakeMaker.
>
> Like anything else in make, if any of the subtest commands fail the whole
> thing will fail.

OK. Won't that complicate the producing of smoke reports ? Let's ask
the smoke experts. CC:ing Abe.

Reply via email to