Brian,
Thanks for the helpful explanation. I'm moving this over to vmsperl
as others may have insights about how to get around the problems.
Inline looks like a nifty module and we look forward to getting it
working on VMS.
At 6:18 PM -0800 3/15/01, Brian Ingerson wrote:
>"Craig A. Berry" wrote:
> >
> > Jarkko wrote:
> >
>> >A propos, you might pre-emptively check how well Inline works in VMS.
>> >(I trust that Digest::MD5 is known to work well.)
>>
>> Digest::MD5 tests out fine. Inline blows up big-time. I will try to
>
>Well I should hope so ;)
>
>> get under the hood and look at the root cause(s) of these failures,
>> but here's a dump of the tests. This was Inline 0.32 against
>> perl@9172 on OpenVMS Alpha V7.2-1. I'm afraid the "does not support"
>> error message is rather confusing; is there supposed to be a "not"
>> between "does" and "properly"?
>
>Oops. :(
>
>>
>> $ mmk test
>> olddef = F$Environment("Default")
>> Set Default [.c]
>> MMK all /Macro=(LIB="", LIBPERL_A="libperl.olb",
>> LINKTYPE="dynamic", PREFIX="/BRIANA$DKA0/CRAIG/PERL/",
>> OPTIMIZE="/O
>> ptimize")
>> olddef = F$Environment("Default")
>> Set Default [.grammar]
>>
>>MMK/MACRO=(LIB="",LIBPERL_A="libperl.olb",LINKTYPE="dynamic",PREFIX="/BRIANA$DKA0/CRAIG/PERL/",OPTIMIZE="/Optimize")
>> all /Macro=(LIB
>> ="", LIBPERL_A="libperl.olb", LINKTYPE="dynamic",
>> PREFIX="/BRIANA$DKA0/CRAIG/PERL/", OPTIMIZE="/Optimize")
>> Set Default 'olddef'
>> Set Default 'olddef'
>> perl "-I[.blib.arch]" "-I[.blib.lib]" "-Iperl_root:[lib]"
>> "-Iperl_root:[lib.VMS_AXP.5_7_0]" -e "use Test::Harness
>> qw(&runtests $
>> verbose); $verbose=0; runtests @ARGV;" t/*.t
>> t/aaa...............
>> ok
>> t/create............
>> The module Inline::c does not support the Inline API, because it does
>> properly support the register() method. This module will not work
>>with Inline
>> and should be uninstalled from your system. Please advise your sysadmin.
>>
>> The following error was generating from this module:
>> Undefined subroutine &Inline::c::register called at (eval 2) line 1,
>> <DATA> line 6.
>
>This is happening in Inline::create_config_file(). The first time you
>run Inline against a new cache directory, Inline creates a file called
>'config'. It scans your system for possible ILSMs (Inline Language
>Support Modules) and invokes their register() method. This method allows
>an ILSM to describe itself. Since loading one of these modules can be
>expensive, Inline caches the ILSM attributes in the config file. That
>way the ILSM only needs to be loaded when an actual compile happens.
>
>The problem here, I'm guessing, is that VMS is case insensitive, and
>worse yet, its readdir() implementation forces file names to lower case.
>This is probably why it's trying to call Inline::c::register instead of
>Inline::C::register.
Yup, good guess. The C RTL does indeed convert filenames to
lower case, though they are stored in upper case in the directory file.
>The good news is that I wanted to rewrite this logic anyway. But maybe I
>cannot depend on readdir(). Is there another way that I can scan the
>site lib accurately for Inline::* files?
Well, readdir() does scan accurately; it's just that it's accurately
reporting the contents of a case insensitive filesystem (there is a
case sensitive volume format available for some systems, but you
can't depend on its presence). I don't know of any way that module
names or other mixed-case identifiers can be reversibly matched up
with file names. Can we start with a list of what we are looking for
and see if it exists rather than vice versa? I.e., say to the
filesystem, "Do you have 'Foo'?" rather than reading 'foo' from the
filesystem and later finding that it fails to match 'Foo'? (I hope
the question is not too stupid -- I haven't read the code in any
detail yet.)
>FYI, I have no experience with VMS. Can you point me to a good web
>resource? I would really like to get this working. I've bumped into some
>VMS specific code along my Inline journey. Definitely a different
>animal. I do have a strong MVS and VSE background though, if that helps.
VMS will be a piece of cake compared to mainframe-land; characters
are ASCII and the bytes all have 8 bits :-). The vendor home page
(um, I mean "portal") is at <http://www.openvms.compaq.com>, with a
very long and detailed FAQ at
<http://www.openvms.compaq.com/wizard/openvms_faq.html>. OS docs are
available at <http://www.openvms.compaq.com:8000>. C compiler and
RTL docs are at
<http://www.openvms.compaq.com/commercial/c/index_alpha.htm>. Your
best bet, though, is probably to just post to vmsperl with specific
questions.
>My first question is: "What is the current state of the extension
>building tools? Do XS, MakeMaker, and DynaLoader work reliably?" If so,
>we have a fighting chance.
Yes, many, many extensions build just find under VMS. DynaLoader
obviously has to use native methods for loading dynamic libraries
(known as shareable images); if you are doing something unusual like
creating and loading dynamic libraries on the fly then that could get
interesting.
On a very cursory scan of your code I see quite a few filenames being
constructed by pasting together tokens and slashes; VMS supports
Unix-style file specs in many (but not all) contexts, but some
platforms may choke entirely on the resulting names. You'll probably
want to make friends with File::Spec->catdir() and
File::Spec->catfile().
--
____________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
