Re: Rethinking how ext/ is tested

Craig A. Berry wrote:
> On Fri, Feb 27, 2009 at 5:14 PM, demerphq <[email protected]> wrote:
>> 2009/2/27 Michael G Schwern <[email protected]>:
> 
>>> The plan changed in the middle of this argument and I think that wast lost.  I
>>> no longer plan to do it with make subtests but rather by hacking t/TEST and
>>> t/harness.  It should work out to no visible change.  Rather than untangle the
>>> miscommunication in email its simpler and faster for me to just do it and let
>>> the code speak for itself.
>> That sounds great!
> 
> Yes, indeed.  Even if the hacks are wicked they'll be corralled into
> one or two places where we can keep an eye on them.

It is done.  Or at least, it is demonstratable.
http://github.com/schwern/perl/tree/ExtUtils-MakeMaker

The effective change to the testing system is rather small.  Here you can see
it without refactorings.
git diff 1a129493906affc7fd0e26067910a344e22fb5f2^..HEAD t/TEST t/TestInit.pm

I altered t/TEST to run ext/Module tests from ext/Module.  This leaves how
tests are run outwardly unchanged.  I then stripped all the PERL_CORE path
hackery out of the ext/ tests which is what really consumed all the time.  I
kept changes to a minimum and in separate commits for each module to
facilitate pushing them back to the authors.

In some cases I moved files out of t/ and back into ext/ when doing so would
restore the integrity of a CPAN distribution and eliminate a PERL_CORE hack.
t/Module_Pluggable for example.  I realize some of the moves were made because
of VMS depth limits.  I think now that ext has been flattened this should be
ok.  If not, a better solution might be for TEST to create a VMS virtual root
for each ext/Module and chdir into that.

I also made the path to perl and the lib directories absolute so tests can
chdir safely and added "." into @INC so it's more like how perl really runs.

One debatable bit is t/TEST's use of File::Spec->rel2abs.  TEST was already
using File::Spec but now its also using Cwd.  Fortunately, Cwd can work as a
Perl module.  Also, if things go really bad, you can run TEST using an already
installed Perl.  Even a rather old one should work.

t/harness still needs to be dealt with.  And the system for copying
ext/ExtUtils-MakeMaker/lib into lib is incomplete.  I'm not sure how that
should best be done.  Ideally I'd like make to take care of it so that as
ext/ExtUtils-MakeMaker/lib is edited, it will be copied into lib as necessary.


-- 
<Schwern> What we learned was if you get confused, grab someone and swing
          them around a few times
        -- Life's lessons from square dancing