Perl ships with an extensive test suite, covering the interpreter itself and most of the modules. To run a full test, use
(cd t && ./perl harness)or just
make testThis works just as well with perl-cross — assuming you do it on the target from within a full perl build tree. Depending on the target, the latter part may not be practical, and actually makes little sense when you think of it.
perl-cross provides an alternative way for on-target testing: testpack, tarball with the tests (and little else) that can be transferred to the target. It's must smaller than the perl tree, ~23MB instead of 150+MB, and unlike make test it's set up to test the perl that's already installed in its proper location.
To make the pack, run
make testpackthen transfer TESTPACK.tar.gz to the target, unpack it there and do
(cd TESTPACK/t/ && ./perl harness)Run
make clean-testpackin the source tree to remove TESTPACK/ if necessary after TESTPACK.tar.gz has been built.
At this point testpack does not include all the tests that make test does. So if you need to make absolutely sure the perl passes every test, do transfer the whole build tree and run make test instead. However, testpack should be more than enough to catch bad cross-compiling issues.
Just like the rest of the language, perl testsuite is one big hack with a lot of counter-intuitive and counter-productive issues no-one bothers to fix. Following the tradition, I merely document some of them here.
./perl harness ../cpan/Archive-Extract/t/01_Archive-Extract.tfrom the t/ directory. It is possible to run some of the tests without harness, but others will fail with bogus error messages.
Check TESTPACK.px, namely %exclude hash at the top.
Short summary: porting/, most of ExtUtils, CPAN meta-modules and some XS stuff is excluded, the rest should work. Given the nature of the excluded tests, they will probably never work well with cross-builds. Also, XS::APItest and anything that depends on it.