Gabor Szabo wrote: > On Sun, Nov 8, 2009 at 9:53 PM, Christian Soeller > <[email protected]> wrote: >> On 9/11/2009, at 4:08 AM, Chris Marshall wrote: >>> Also, be sure you don't have another copy of PDL in your @INC >>> when you are running the tests as that can result in mysterious >>> and highly confusing failures... >>> >> This is a really *glaring* weakness of the current testing environment >> (which I have run foul of myself). Is PDL the only large installation >> suffering from this? >> How can one fix this? Are CPAN testers potentially affected? > > > I have not looked at the test suit of PDL but normally any test should use the > files in the blib/ directory. > > make test does this by adding -Iblib/lib > prove -b does this (the -b flag stand for blib) > > So if a test file has use PDL::XYZ; in it, that will be loaded > from blib/ and it will be loaded from the old installation only if the > current PDL installation did not compile that module. > > If I understand the problem is that the old modules might not work > together with the newly compiled modules probably because of binary > or API incompatibilities. > If that is the case then actually the test failure is correct as the thing > will > fail also when the user is tying to run the code.
It is trickier than that. The problem is an old PDL with features A, B, and C in @INC. Then you download, build and test PDL with features A and C (either because you set the perldl.conf option, you did not have the right libraries and headers,...). Now the tests run. Unfortunately, the current tests don't check that you built A and C so *only* test A and C. It is useful to know there is a potential problem but we need to know that the source of the problem is version skew between an existing PDL in @INC and not a problem with the new build. NOTE: This problem does not arise too often since most folks keep building the same options all the time. Nonetheless, this fix would really help stop a completely preventable but totally mysterious failure mode for PDL installs. > Of course you might say that you want to let the user upgrade PDL > partially with the knowledge that s/he will be able to use only part of PDL. Nope, PDL pretty much is a reinstall all kind of thing right now. > If you want to allow this then the test suit should be also aware of > what was built in the current build and skip the tests > (using plan skip_all or SKIP blocks) that would require parts of PDL that > are not expected to work. > > For this maybe a better approach would be to split up PDL - as has been > discussed recently - into CPAN packages that can be either built and tested > separately. This can solve part of the issues though it won't solve issues of > compilation flags that simply alter the behavior of the package. For that > one will have to make sure the tests are aware of the capabilities of the > current build. For diagnostic purposes, we need to make an understandable record of what is actually built and installed by PDL. As we configure for the build, we already know what submodules are being built. Those are the ones that should be tested which is the focus of this fix. --Chris _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
