Install Perl extension modules

[john nicoara]

Hello Perl fans,
I'm bothered with the installation of extra perl modules on Alpha/VMS 8.3/Perl 5.8-6:
The standard procedure of build, test and install, like

perl Makefile.PL
mms
mms test
mms install

fails on the step "test", but the install nevertheless does succeed! (the same if using MMK instead of MMS)

I tried that with a lot of modules, none was successful on test, even the simplest one; but using these modules in my programs works ok!
Did somebody experience the same phenomenon? Where could the problem lie?

john

[Craig A Berry]

It completely depends on what those extensions are and what their test suites are trying to do. I have built many Perl extensions that tested out just fine, but also seen many with test failures. The failures could mean anything from the tests aren't written portably (and the test suite is often the least portable part of a Perl extension), or some of the functionality provided by the extension is not working on VMS, or the extension needs anything from a minor portability update to a complete rewrite to work on VMS, or anything in between.

The install step does not depend on the results of the test step. Evaluating the test status before installing is expected to require human intervention.

There is no valid answer that can be given in the abstract or in general. If the installed extensions do everything you want them to do and you are satisfied with your own testing, then you're all set. Otherwise you'll need to delve into why the failures are occurring. Watching them happen in the Perl debugger is often instructive.

[Hoff]

My experience has been that various of the mainstream extensions "just work" -- or that the failures are pretty clearly bogus tests -- which implies you're somewhat off in the weeds with whichever perl module(s) you're working with here.

If you've not encountered it, a number of the perl experts (including Craig) have tended to lurk on the Perl VMS mailing list.

In addition to the module(s) involved, some details on the failure(s) would be useful; some information around what might be needed to try to replicate this. And some idea of the source of this perl 5.8.6 kit, too -- did you build it from source, or is this a kit that was downloaded from HP or somewhere else?

[john nicoara]

Indeed, is the (rhetoric) question "why should I worry about the test status if the installation succeeds?" worth of consideration, if my application using that module runs correctly? It depends of my objective: use it for fun or for some professional deployment. In the last case, it would be quite tedious to explain to somebody, why do I use components which did not pass standard validation steps?

Anyway, coming back to that test issue, I can exclude considering any portability aspects, as the installed Perl is the binary kit prepared by HP and one of the test-failing modules I considered is just one written for an OpenVMS platform (VMS::Device 0-09; Craig, do you remember the mail exchange we had on this topics last August? By the way, my last mail remained un-answered...). What I could firmly state, is that the bug is insensitive to using MMK (instead of MMS) or ODS-2/-5 disks (with extended parse style). The attached sample installation (of VMS::Device) should give a view of what's gone on.

[Craig A Berry · Accepted solution]

John,

I thought your name sounded familiar :-). I can't reproduce your problem with any Perl I have handy (5.8.4, and a pre-release copy of 5.10.0). I always get:

$ mmk test
MCR dsa0:[sys0.syscommon.perl-5_8_4]perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, '[.blib.lib]', '[.blib.arch]')" t/*.t
t/basic....
ok
All tests successful.
Files=1, Tests=1, 1 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)

So there must be something in your environment that is preventing the test from locating the module. The reason it works after installation is that it can then locate the installed version of it. ( Normally testing involves overriding the default library locations to make sure you run what you've just built and not yet installed, but that is all handled inside of the descrip.mms or things invoked from it.)

You might check whether you have a PERL5LIB logical name defined and deassign it if you can, and see if you have any other logicals with "perl" in the name. You could also review your DECC$* logical names if any. And if you have a logical name "VMS" defined, or "DEVICE", there is some possibility that could throw a wrench in loading a module called VMS::Device.

But in any case, there's nothing obviously wrong with VMS::Device. You can probably run the test manually like so:

$ perl -"I[.blib.lib]" -"I[.blib.arch]" [.t]basic.t

From your original post, it sounds like the problem is happening with all extension testing, so you do appear to have a general problem in your environment. I suggest you use whatever debugging techniques you are comfortable with to see where it's looking and why. SET WATCH FILE might be a good approach if you have the privs.