"Craig A. Berry" wrote:
> At 4:27 PM -0800 3/16/01, Brian Ingerson wrote:
> >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.
> So users of Inline on VMS would actually be using a subclass called
> Inline::vms, which might have a completely different implementation
> from the Unix version? I agree this is a cool way to do it if a
> different implementation is necessary. However, all the problems
> I've encountered so far arise from assuming a Unix filesystem. I'd
> vote for resolving as many of the basic portability issues as
> possible before getting fancy with the OO stuff. For example, after
> the following patch Inline::C can find the typemap on VMS, but it
> should also be able to find it on any platform including Unix, and
> without the need for separately-maintained versions of the code:
I agree with all the above. I just want to avoid making Inline look like
File::Path, which has more VMS code than File::Path code. ;)
> There are two problems here, one the double slash before "build,"
> which I assume would be a problem even on Unix, and the other is the
> extremely long directory name. The most common volume format on VMS
> has a limit of 39.39, but I believe Perl also supports 8.3 and 14.3
> filesystems which would run into trouble far sooner. For creating
> temporary directory names portably you might consider using
> File::Temp, where the porting work has already been done.
If filename lengths are a problem, this is a showstopper (at least for
now). It's not just the temporary files that have long names. The final
"installed" executable also has a very long filename. For example a
executable called Foo normally gets installed as:
/some_perl_lib_path/auto/Foo/Foo.so
If '/some_perl_lib_path/' is in @INC, Perl can find the executable.
Since my names have md5 keys in them, I need to install the modules as:
/some_perl_lib_path/auto/Foo_C_033f0bc5ea371715666063f485f4d4b2/Foo_C_033f0bc5ea371715666063f485f4d4b2.so
Luckily, I have plans to change all that by putting the md5 key in a
separate file like this:
/some_perl_lib_path/auto/Foo/Foo.so
/some_perl_lib_path/auto/Foo/Foo.inl
The '.inl' file will contain all of the Inline required meta data, like
md5 key, and external dependencies, and binary compatibility info.
I have this all planned out, but with my current schedule, I don't see
it being finished until mid to late April.
> All of the path manipulation methods in Inline do a lot of twiddling
> with forward slashes, which is a major portability no-no. mkpath()
> looks for colons in case there is a DOS/Windows device spec in the
> path, but of course colons mean something different on Mac OS. It's
> really best to stick with the File::Spec family for creating and
> manipulating paths.
In the meantime I'll keep these portability issues in mind, and try to
clean stuff up along the way. Then we can give this another go.
Cheers, Brian
--
perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf
("Just Another %s Hacker",x);}};print JAxH+Perl'
