At 3:18 PM -0600 12/28/01, Dave Rolsky wrote:
>It seems to me that this could be fixed in the following manner. In all
>places where the MM_* code has references to $(FOO) or (after your patch)
>$self->{FOO}, simply replace both of those constructs with
>'$self->get("foo")'.
>
>The get method will look like this for Unix:
>
>sub get { return "\$($_[1])" }
>
>and for VMS something that contains the logic currently in
>File::Spec::VMS::eliminate_macros.
Does that assume every macro should be expanded? Some should and some
shouldn't and I'm not sure I completely know what the rules are. In
general if a macro is part (but not all) of a file or directory spec
it should be expanded, but there may be other cases. Also, macro
expansion needs to be recursive because a macro may expand to a
string that contains one or more other macros.
> > If File::Spec::VMS->catdir and File::Spec::VMS->catfile were
>> expanding macros as they're supposed to, I don't think we'd see this
>> problem. But they can't expand macros when the methods they depend
>> on to do that (fixpath and eliminate_macros) don't have access to
>> MM's %self array. How criminally insane would it be to export that
> > array into File::Spec?
>Well, if the macro futzing can be done before calling into File::Spec it
>should work. I don't completely understand all the intricacies but I
>think it can be done. What I suggested above should take care of some of
>it. Most of what fixpath seems to do has to do with properly calling
>eliminate_macros. If the macros are never passed into File::Spec (because
>they're expanded first) then it should work.
That means, for example, calling eliminate_macros or equivalent on
each of the arguments to catdir before every catdir call in
MakeMaker, MM_Unix, Liblist, and MM_VMS instead of having catdir do
it internally. Is that really preferable?
> > No more so than it is already. If we work out the right way to do
>> this for MM_VMS, the same thing should work for Liblist.
>
>Ok, I'll submit a patch for Liblist sometime.
Note that there are a couple of places in MakeMaker.pm also.
This is turning into a rather major rearchitecting of how MakeMaker
works on VMS, and that very likely needs doing, but I have yet to see
or think of anything that is preferable to the way it was before.
--
____________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"Literary critics usually know what they're
talking about. Even if they're wrong."
-- Perl creator Larry Wall
