"Craig A. Berry" wrote:
> 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.)
Since people may be constantly adding new languages (with or without my
involvement), I need a mechanism that allows Inline to discover these
modules as they are installed. So I can't really go through a list like
you suggest...
... At least not in the *general* case. VMS (IMO) is *not* the general
case. So I actually *can* do what you want, when I know I'm dealing with
VMS. :)
> >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().
I think I have a good idea on how to approach this port. Inline uses OO
style calling for 90% of its internal processing. The way it works is:
1) Programmer says 'use Inline C => "source-code" ...' which
2) calls Inline::import() which
3) creates an internal object blessed into class 'Inline'.
4) Inline then uses the object to call it's various internals and
gathers data into the object along the way.
5) If Inline determines that it needs to compile the (let's assume C)
source code, it requires Inline::C and
6) reblesses the object into class 'Inline::C' which *ISA* 'Inline'.
7) It then can invoke the $o->build() method which Inline::C is mandated
to supply.
8) Inline::C also uses the object to call *its* internals some of which
might be in Inline.pm (the superclass)
The reason this is so cool for VMS (and others) is that I can write an
intermediary class called Inline::vms which will provide VMS specific
logic. That way there will be no impact on existing platforms. Also,
after I set up the basic framework for this, I can turn Inline::vms over
to you (or people like you ;) to work on.
Thoughts or Comments?
Brian
--
perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf
("Just Another %s Hacker",x);}};print JAxH+Perl'
