At 5:07 PM -0400 6/4/06, John E. Malmberg wrote:
>Craig A. Berry wrote:
>>At 11:56 PM -0400 6/3/06, John E. Malmberg wrote:
>>>
>>>I have discovered that Perl on OpenVMS has components that expect
>>>UNIX style shell macros in file specifications to be translated
>>>intact through vmsify() and unixify().
>
>>What components of Perl, specifically?
>
>RSYNC_ROOT:[PERL.lib.ExtUtils]MM_VMS.pm;1
>
> $(ZIP) "$(ZIPFLAGS)" $(MMS$TARGET) [.$(DISTVNAME)...]*.*;
> $(TAR) "$(TARFLAGS)" $(DISTVNAME).tar [.$(DISTVNAME)...]
> $(SHAR) [.$(DISTVNAME)...]*.*; $(DISTVNAME).share
Those macros are part of complete targets, not filespecs, and are
clearly intended to go through to the make utility as is. I can't
think of any reason they would go through vmsify() or unixify(); if
they do, please let me know where and when.
>
>RSYNC_ROOT:[PERL.ext.DynaLoader]Makefile.PL;1
>
> $(RM_RF) $(PERL_SRC)/$(OBJECT)
> $(CP) $(OBJECT) $(PERL_SRC)/$(OBJECT)
Generally speaking, the static target in DynaLoader is a non-portable
no-no because it explicitly pieces a filespec together with a
platform-specific slash in it. Practically speaking, it doesn't
matter because on VMS, DynaLoader is a special case and the code to
build it is in vms/descrip_mms.template -- this Makefile.PL is not
used.
>
>>The only unexpanded macro that can be safely "passed through to make
>>type programs" on VMS is one that you know will expand to a complete
>>(not partial) and syntactically valid VMS filespec, or one where you
>>have taken care to ensure that the components will assemble
>>themselves in a valid way after expansion. If you want to perform
>>conversions or concatenations or other operations on a string that is
>>a filespec with a macro embedded in it or a macro that has only part
>>of a filespec in it, your best bet is to expand the macros first.
>>That's why eliminate_macros() started out in MM_VMS rather than
>>File::Spec (probably before File::Spec even existed).
>
>From mailing list conversations with Michael G. Schwern, it appears that the
>only reason for eliminate_macros() is because Perl on OpenVMS was storing
>environment variables in logical names instead of symbols.
>
>Because MMS/MMK was not expanding those macros, an incorrect assumption was
>made that macro handling in MMS/MMK was broken and eliminate_macros() was
>created to hack around it.
That's definitely not why eliminate_macros() was created. It's
primary (only?) purpose is to solve the problems that arise when
concatenating filespecs on VMS. Because the different parts of the
filename are distinguished by syntax, you have to be able to see that
syntax in order to do a valid concatenation. For example, suppose I
simply concatenate
$ perl -"MFile::Spec::Functions" -e "print catfile('$(foo)', '$(bar)',
'$(baz)');"
[.$(foo).$(bar)]$(baz)
But lets say those macros have the following definitions:
foo = dev:
bar = dir1
baz = file.ext
If I were to expand those after concatenating, I would get,
[.dev:.dir1]file.ext, which is obviously not a valid filespec, and is
not the same as the valid dev:[dir1]file.ext that I get if I do the
macro expansion first. There is no way catfile can know that $(foo)
holds a device name unless the macro is expanded first.
>If Perl on OpenVMS is converted so that MakeMaker is putting the environment
>variables into DCL symbols, then the restriction would be for what DCL will
>allow a symbol to have.
Under what conditions does MakeMaker depend on environment variables
for macro definitions? The ones I know about are all explicitly
written to the Makefile.
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
