Re: Rethinking how ext/ is tested

Craig A. Berry wrote:
>> The important thing is the core change from running the ext/ tests manually to
>> using each module's own "make test".  This will make integrating and
>> developing dual life modules far easier by eliminating a key difference in how
>> ext/ and CPAN modules are developed.
> 
> Hmm.  This only makes any difference for modules that distribute their
> own libraries that are only used for testing, right?  It looks like
> ext/Test-Harness/t/lib is the only one like that currently.  Add
> Module::Build and ExtUtils::MakeMaker when they get moved to ext/,
> maybe a couple others.

It's a general purpose problem that effects all the ext/ modules.  Most tests
have some special code to accommodate the duality of core vs CPAN testing.
Usually its just this:

BEGIN {
    if ($ENV{'PERL_CORE'}){
        chdir 't';
        unshift @INC, '../lib';
    }
}

But it will effect any test that needs to know its position relative its
source tree, usually to read another file or load a module in the source tree.
CPANPLUS and CPAN are good examples off the top of my head.  But it's not
limited to just finding stuff in their own t/lib.

Rather than look at this as "its an exception for a few modules in ext" turn
it around.  All the dual lifed modules currently scattered around lib/ are the
exceptions.  If we can pull them back together and put them in ext it will
make integration easier both for p5p and the CPAN maintainers.  This is the
base assumption I'm working under.

The more we do this, the more we're going to find "exceptions", the more hacks
we have to put into place and what's going to wind up happening is we're not
going to want to move things into ext.  Making ext/ as much like the normal
module process as possible smooths out the transition.


-- 
Being faith-based doesn't trump reality.
	-- Bruce Sterling