Making tests run anywhere
Ilya Zakharevich
whether Perl works. As a first step, one could do edits like this one
(sorry, reverted):
--- ./t/op/pack.t-edited Mon May 5 13:26:42 2003
+++ ./t/op/pack.t Wed Mar 19 02:52:20 2003
@@ -1,10 +1,8 @@
#!./perl -w
BEGIN {
- unless ($ENV{NO_PERL_CORE}) {
chdir 't' if -d 't';
@INC = '../lib';
- }
require './test.pl';
}
The target is to be able to unbundle the test suite (e.g., to test
binary distributions).
Yours,
Ilya
Rafael Garcia-Suarez
Ooh, clever. What's the goal precisely ? to unbundle t/ and lib/[a-z]*.t ?
(i.e. the "coretest" as Makefile defines it).
--
Undo is not *NIX
Ilya Zakharevich
> > --- ./t/op/pack.t-edited Mon May 5 13:26:42 2003
> > +++ ./t/op/pack.t Wed Mar 19 02:52:20 2003
> > @@ -1,10 +1,8 @@
> > #!./perl -w
> >
> > BEGIN {
> > - unless ($ENV{NO_PERL_CORE}) {
> > chdir 't' if -d 't';
> > @INC = '../lib';
> > - }
> > require './test.pl';
> > }
> > The target is to be able to unbundle the test suite (e.g., to test
> > binary distributions).
> Ooh, clever. What's the goal precisely ? to unbundle t/ and lib/[a-z]*.t ?
> (i.e. the "coretest" as Makefile defines it).
Basically, one should be able to run the test suite against the
*installed* perl, not the *built* perl. E.g., with binary
distributions one has no build tree, but it is useful to know which
tests do not work. The other case is when one has a build tree, but
one want to check that `make install' does not break things.
Being able to unbundle t/* and lib/**/*.t is also a useful target.
BTW, maybe it is easier to do the edit like this:
BEGIN {
chdir 't' if -d 't';
- @INC = '../lib';
+ @INC = '../lib' if -r '../lib/lib_pm.PL';
require './test.pl';
}
(I choose a file which is not probable to be present outside of the
build tree).
Yours,
Ilya
Rafael Garcia-Suarez
>
> Basically, one should be able to run the test suite against the
> *installed* perl, not the *built* perl. E.g., with binary
> distributions one has no build tree, but it is useful to know which
> tests do not work. The other case is when one has a build tree, but
> one want to check that `make install' does not break things.
>
> Being able to unbundle t/* and lib/**/*.t is also a useful target.
> BTW, maybe it is easier to do the edit like this:
>
> BEGIN {
> chdir 't' if -d 't';
> - @INC = '../lib';
> + @INC = '../lib' if -r '../lib/lib_pm.PL';
> require './test.pl';
> }
>
> (I choose a file which is not probable to be present outside of the
> build tree).
Other proposal :
BEGIN {
chdir 't' if -d 't';
# File::Spec::file_name_is_absolute would be better than
# the match below, but are we going to allow an external module ?
@INC = '../lib' unless defined $ENV{PERL} && $ENV{PERL} =~ m(^/);
require './test.pl';
}
This way, one could run coretests from a full-fledged perl source tree,
against an installed perl, by doing
$ cd t
$ PERL=/some/installed/perl perl ./TEST -core
(t/TEST has already support for the PERL environment variable. t/harness
doesn't, as it uses always $^X, IIRC, but I think that can be added
somehow.)
--
Uncontrolled is not *NIX
Ilya Zakharevich
> BEGIN {
> chdir 't' if -d 't';
> # File::Spec::file_name_is_absolute would be better than
> # the match below, but are we going to allow an external module ?
> @INC = '../lib' unless defined $ENV{PERL} && $ENV{PERL} =~ m(^/);
Not good on DOSISH - where the need is the most. Why not use a
different environment variable?
> require './test.pl';
> }
>
> This way, one could run coretests from a full-fledged perl source tree,
> against an installed perl, by doing
>
> $ cd t
> $ PERL=/some/installed/perl perl ./TEST -core
>
> (t/TEST has already support for the PERL environment variable. t/harness
> doesn't, as it uses always $^X, IIRC, but I think that can be added
> somehow.)
Then
cd t
PERL=/some/installed/perl /some/installed/perl ./TEST -core
[I do not think ./TEST is a relevant tool for the job.] Of course,
there is an eternal topic of which DLLs are picked up...
BTW, are the non-core tests unbundle-able? Meaning that copying
lib/**.t (and a minimal amount of support files) into a separate
directory, one can run t/harness using these files? If yes, is not it
good to have the current list of support files in MANIFEST.test (or
mark them in MANIFEST)?
Yours,
Ilya
Rafael Garcia-Suarez
> On Tue, May 06, 2003 at 09:55:11AM +0200, Rafael Garcia-Suarez wrote:
> > BEGIN {
> > chdir 't' if -d 't';
> > # File::Spec::file_name_is_absolute would be better than
> > # the match below, but are we going to allow an external module ?
> > @INC = '../lib' unless defined $ENV{PERL} && $ENV{PERL} =~ m(^/);
>
> Not good on DOSISH - where the need is the most. Why not use a
> different environment variable?
Yes, might be better. Saves headaches. Say, $NO_PERL_CORE, that will also
prevents t/TEST and t/harness to set $PERL_CORE.
> > require './test.pl';
> > }
> >
> > This way, one could run coretests from a full-fledged perl source tree,
> > against an installed perl, by doing
> >
> > $ cd t
> > $ PERL=/some/installed/perl perl ./TEST -core
> >
> > (t/TEST has already support for the PERL environment variable. t/harness
> > doesn't, as it uses always $^X, IIRC, but I think that can be added
> > somehow.)
>
> Then
>
> cd t
> PERL=/some/installed/perl /some/installed/perl ./TEST -core
The perl that runs TEST doesn't really matter.
> [I do not think ./TEST is a relevant tool for the job.] Of course,
> there is an eternal topic of which DLLs are picked up...
That's because t/harness should be adapted. t/TEST already works like
this. I recently updated perlhack.pod to document $PERL.
> BTW, are the non-core tests unbundle-able? Meaning that copying
> lib/**.t (and a minimal amount of support files) into a separate
> directory, one can run t/harness using these files? If yes, is not it
> good to have the current list of support files in MANIFEST.test (or
> mark them in MANIFEST)?
Should be feasible, with a little care.
--
Unassisted is not *NIX
Ilya Zakharevich
> > > $ cd t
> > > $ PERL=/some/installed/perl perl ./TEST -core
> > >
> > > (t/TEST has already support for the PERL environment variable. t/harness
> > > doesn't, as it uses always $^X, IIRC, but I think that can be added
> > > somehow.)
> >
> > Then
> >
> > cd t
> > PERL=/some/installed/perl /some/installed/perl ./TEST -core
>
> The perl that runs TEST doesn't really matter.
Oups, read this as
cd t
PERL=/some/installed/perl /some/installed/perl ./harness
> > [I do not think ./TEST is a relevant tool for the job.] Of course,
> > there is an eternal topic of which DLLs are picked up...
Yours,
Ilya