At 4:27 PM -0800 3/16/01, Brian Ingerson wrote:
>"Craig A. Berry" wrote:
> > 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'?
>
>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. :)
OK, but if we come up with an alternative way of looking to see what
language modules are installed that works on VMS, then why not just
use the same method everywhere rather than maintaining separate
methods? In the meantime, this little hack will work for some of the
obvious cases and let us get on to solving other problems:
--- inline.pm;-0 Thu Mar 1 00:53:11 2001
+++ inline.pm Sat Mar 17 13:02:17 2001
@@ -427,6 +427,7 @@
}
next if $mod eq 'Files';
($mod) = $mod =~ /(.*)/ if UNTAINT;
+ $mod = "\u$mod" if $^O eq 'VMS'; # guess about
mixed-case module name
eval "require Inline::$mod;\$register=&Inline::${mod}::register";
croak usage_register($mod, $@) if $@;
my $language = $register->{language}
>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:
<details snipped>
>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?
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:
--- c/C.pm;-0 Mon Feb 26 17:29:32 2001
+++ c/C.pm Sun Mar 18 11:00:24 2001
@@ -6,6 +6,7 @@
use Parse::RecDescent;
use Config;
use Data::Dumper;
+use File::Spec;
use FindBin;
use Carp;
use Cwd qw(cwd abs_path);
@@ -209,19 +210,21 @@
#==============================================================================
sub get_maps {
my $o = shift;
+ my $tmpfspec = '';
my $typemap = '';
- $typemap = "$Config::Config{installprivlib}/ExtUtils/typemap"
- if -f "$Config::Config{installprivlib}/ExtUtils/typemap";
- $typemap = "$Config::Config{privlibexp}/ExtUtils/typemap"
- if (not $typemap and -f "$Config::Config{privlibexp}/ExtUtils/typemap");
+ $tmpfspec = File::Spec->catfile($Config::Config{installprivlib},
'ExtUtils', 'typemap');
+ $typemap = $tmpfspec if -f $tmpfspec;
+ $tmpfspec = File::Spec->catfile($Config::Config{privlibexp},
'ExtUtils', 'typemap');
+ $typemap = $tmpfspec if -f $tmpfspec;
warn "Can't find the default system typemap file"
if (not $typemap and $^W);
unshift(@{$o->{C}{MAKEFILE}{TYPEMAPS}}, $typemap) if $typemap;
- if (-f "$FindBin::Bin/typemap") {
- push @{$o->{C}{MAKEFILE}{TYPEMAPS}}, "$FindBin::Bin/typemap";
+ $tmpfspec = File::Spec->catfile($FindBin::Bin, 'typemap');
+ if (-f $tmpfspec) {
+ push @{$o->{C}{MAKEFILE}{TYPEMAPS}}, $tmpfspec;
}
}
[end of patch]
So, that's a start, but there are lots of other places that need
similar fixing. After getting it to find the typemap, I next
encountered:
t/config............
Couldn't make directory path
/d0/craig/inline-0_32/c/_inline_test//build/main_C_config_t_733bc9cf492f92228bd721de313b1e50/
at t/config.t line 36
BEGIN failed--compilation aborted at t/config.t line 36.
%RMS-F-SYN, file specification syntax error
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.
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.
I recognize Inline is only at version 0.32 and that there is a
convenience in letting a familiar filesystem do some of the work --
perhaps I haven't even told you anything you didn't already know.
However, most of the work of porting involves attention to these
rather mindless details. There may well be more significant issues
down the road, but we aren't there yet.
--
____________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
