On Thu, 27 Dec 2001, Craig A. Berry wrote:
> 1.) If ExtUtils::MM_VMS no longer inherits from File::Spec, then
> $self->fixpath() and $self->eliminate_macros() are orphaned. If
> these methods are called directly in File::Spec, then their use of
> the $self object refers to File::Spec rather than MakeMaker, but they
> have to consider themselves part of MakeMasker to work in the context
> of MakeMaker. I've restored the inheritance.
Ugh, that is just unholy.
I think tearing these apart is beyond my ability at this point,
particularly since I don't know squat about VMS. And obviously, its
better to have the EU::MM_VMS stuff work than to have it be pretty ;)
But maybe some Perl VMS person could think about how to do that. The fact
that File::Spec::VMS operates differently when called from
ExtUtils::MakeMaker is very weird.
Also, I see that File::Spec::VMS calls $self->fixpath and
$self->eliminate_macros in catdir and catfile. Does that mean that there
will be other problems when File::Spec->catdir (instead of $self->catdir)
is called from ExtUtils::MM_VMS?
Or is that what you're describing down below.
> 2.) Under the previous dispensation, $self->catdir was not equivalent to
> File::Spec->catdir but rather to File::Spec::Unix->catdir. Ditto for
> catfile. As far as I can see this was true on all platforms except
> Win32, which had its own versions with backward slashes instead of
> forward slashes. On VMS we needed the old behavior because the
> following order works:
>
> A. use Unix syntax to concatenate filespecs containing macros
> B. expand macros
> C. convert filespecs from Unix to VMS syntax
>
> but the order we are now getting (which doesn't work) is:
>
> A. use native syntax to concatenate filespecs containing macros
> B. expand macros
>
> Basically you end up seeing things like '[.foo$(DIR).bar]' turned
> into '[.foo[.dir].bar]' and that's not a valid directory spec.
>
> My solution to problem #2 is a bit lame but it's all I could come up
> with after wasting most of a day wrestling with this. I just used
> trial and error to figure out which macros had the problem and
> replaced them with literal values as in "$self->{FOO}" for "$(FOO)".
> Luckily there weren't very many of these. I welcome a better
> suggestion if somebody has one.
Maybe a different method could be created for concatenating macros which
does what the previous code achieved (via a rather strange method!). I
don't know enough about VMS to go into more detail though.
I think using File::Spec for this sort of thing (particularly using
File::Spec::Unix) as some sort of generic toolkit path-like thing toolkit
is not a great design, but I don't know enough about what was being done
previously to offer an alternative.
> BTW, on a related note, I wonder why ExtUtils::Liblist wasn't also
> changed to use the File::Spec methods instead of the $self methods?
Oversight on my part. But if I change it now is it going to hose up VMS?
If not, I'll gladly submit a patch.
> And the patch, which has only been tested on VMS:
Or maybe the chunks of my patch which applied to ExtUtils::MM_VMS should
just be reverted?
-dave
