Re: MM_VMS and File::Spec::VMS.pm intertanglement.
Craig A. Berry wrote: On Fri, Nov 14, 2008 at 8:39 AM, John E. Malmberg <[EMAIL PROTECTED]> wrote: Now about MM_VMS, based on previous e-mail discussions, these routines exist because VMS PERL by default does not map the %ENV hash to DCL shell symbols. They exist because WriteMakefile and its children split and recombine path components all over the place and some of those components are macros. That generally works on Unix because there is no special directory syntax: if $(FOO) expands to 'bar', copying your files to /usr/local/$(FOO) works just fine. But on VMS, you can't pass a macro to catdir and get reasonable results unless catdir expands the macro first. Otherwise, you'd be doing things like copying your files to perl_root:[00.$(FOO)] which would expand to perl_root:[00.[.bar]] and give you a syntax error. That makes sense. If those specific $ENV values put in the makefile where exported using the DCLsym module in the format MMK/MMS could use, then MM_VMS would not need to be eliminating the macros. As far as I know, MMK and MMS map logical names, not DCL symbols, to macros. Nope, DCL symbols, not logical names. This test was done on Eisner:: $ type test.mms sys$login:bar$(test).tmp : sys$login:foo.tmp $ write sys$output "process target bar$(test).tmp" $ open/write xx bar$(test).tmp $ close xx sys$login:foo.tmp : $ write sys$output "process target foo.tmp" $ open/write xx foo.tmp $ close xx $ show sym test %DCL-W-UNDSYM, undefined symbol - check validity and spelling $ test = "_override" $ mmk/descrip = test.mms/log/verify %MMK-I-OPENDESC, reading description file EISNER$DRA3:[DECUSERVE_MODERATOR.MALMB ERG]TEST.MMS;10 %MMK-I-CHECKUPD, checking need to update target SYS$LOGIN:BAR_OVERRIDE.TMP %MMK-I-TRGLKUF, lookup for target SYS$LOGIN:BAR_OVERRIDE.TMP failed - update required -RMS-E-FNF, file not found %MMK-I-CHECKUPD, checking need to update target SYS$LOGIN:FOO.TMP %MMK-I-TRGRDT, target SYS$LOGIN:FOO.TMP revision date is 14-NOV-2008 11:59:55.40 %MMK-I-TRGNUPD, target SYS$LOGIN:BAR_OVERRIDE.TMP is out of date - update requir ed %MMK-I-PERFUPD, performing actions to update SYS$LOGIN:BAR_OVERRIDE.TMP $ write sys$output "process target bar_override.tmp" process target bar_override.tmp $ open/write xx bar_override.tmp $ close xx $ del/sym test $ define test logical $ mmk/descrip = test.mms/log/verify %MMK-I-OPENDESC, reading description file EISNER$DRA3:[DECUSERVE_MODERATOR.MALMB ERG]TEST.MMS;10 %MMK-I-CHECKUPD, checking need to update target SYS$LOGIN:BAR.TMP %MMK-I-TRGRDT, target SYS$LOGIN:BAR.TMP revision date is 14-NOV-2008 11:59:55.41 %MMK-I-CHECKUPD, checking need to update target SYS$LOGIN:FOO.TMP %MMK-I-TRGRDT, target SYS$LOGIN:FOO.TMP revision date is 14-NOV-2008 11:59:55.40 %MMK-I-SRCRDT, source SYS$LOGIN:FOO.TMP revision date is 14-NOV-2008 11:59:55.40 %MMK-S-NOUPDATE, target SYS$LOGIN:BAR.TMP is up-to-date $ Now with the macros elimninated on VMS, the resulting makefile can be run outside of the script that generated it, and it will still work. But if it were changed to have the environment variables set by perl, then the resulting makefile would probably only be runnable by the script that generated it, because that is also what set the environment variables. But that should also be the case with UNIX. Or am I missing something here? I'm not quite following what you are proposing. I think I did something for macro propagation in Module::Build's compatibility mode, which might be worth a look. Also, MMK/MMS should be able to use UNIX filename syntax, as long as every file reference is in UNIX format. That should be able to simplify the work in getting mm_vms to support the extended character set mode. Er, assuming major rewrites of MMK and/or MMS to handle Unix syntax filenames, which they currently don't handle at all. My mistake. I thought I had tested MMK and MMS with UNIX format names. I just tried again, and got syntax errors for my trouble. -John [EMAIL PROTECTED] Personal Opinion Only
Re: MM_VMS and File::Spec::VMS.pm intertanglement.
Craig A. Berry wrote: On Wed, Nov 12, 2008 at 10:13 PM, Michael G Schwern <[EMAIL PROTECTED]> wrote: John E. Malmberg wrote: Putting a print STDERR statement shows that is not the case, that the methods of those names contained in File::Spec::VMS are used unless they are called by MM_VMS. The internal calls to eliminate_macros() and fixpath() should simply be removed from File::Spec::VMS. They're only used to deal with make macros, its a very MakeMaker specific thing. They were left in place so that new versions of File::Spec would continue to work with older (pre 6.11 which is from perl 5.8.0 and older) versions of MakeMaker. That was five and a half years ago. It's safe to remove them. Whether it's safe or not it's certainly worth a try. There are a *lot* more tests now for MM, File::Spec, and all the core modules that use File::Spec than there were five and half years ago, so if removing these breaks something I think we'd know pretty quickly. I am not planning on removing those routines for the default mode of VMS, but will not be using them when the DECC$EFS_CHARSET mode is enabled. In addition to eliminating macros, they can change the file specification, and existing scripts ported to VMS may expect this file spec change. My goal with the EFS_CHARSET and REPORT_UNIX modes is to be able to run generic Perl scripts with out having to modify them specifically for VMS, as that is what I am encountering on open source build procedures. Now about MM_VMS, based on previous e-mail discussions, these routines exist because VMS PERL by default does not map the %ENV hash to DCL shell symbols. If those specific $ENV values put in the makefile where exported using the DCLsym module in the format MMK/MMS could use, then MM_VMS would not need to be eliminating the macros. Now with the macros elimninated on VMS, the resulting makefile can be run outside of the script that generated it, and it will still work. But if it were changed to have the environment variables set by perl, then the resulting makefile would probably only be runnable by the script that generated it, because that is also what set the environment variables. But that should also be the case with UNIX. Or am I missing something here? Also, MMK/MMS should be able to use UNIX filename syntax, as long as every file reference is in UNIX format. That should be able to simplify the work in getting mm_vms to support the extended character set mode. -John [EMAIL PROTECTED] Personal Opinion Only
Re: MM_VMS and File::Spec::VMS.pm intertanglement.
On Fri, Nov 14, 2008 at 8:39 AM, John E. Malmberg <[EMAIL PROTECTED]> wrote: > Now about MM_VMS, based on previous e-mail discussions, these routines exist > because VMS PERL by default does not map the %ENV hash to DCL shell symbols. They exist because WriteMakefile and its children split and recombine path components all over the place and some of those components are macros. That generally works on Unix because there is no special directory syntax: if $(FOO) expands to 'bar', copying your files to /usr/local/$(FOO) works just fine. But on VMS, you can't pass a macro to catdir and get reasonable results unless catdir expands the macro first. Otherwise, you'd be doing things like copying your files to perl_root:[00.$(FOO)] which would expand to perl_root:[00.[.bar]] and give you a syntax error. > If those specific $ENV values put in the makefile where exported using the > DCLsym module in the format MMK/MMS could use, then MM_VMS would not need to > be eliminating the macros. As far as I know, MMK and MMS map logical names, not DCL symbols, to macros. > Now with the macros elimninated on VMS, the resulting makefile can be run > outside of the script that generated it, and it will still work. > > But if it were changed to have the environment variables set by perl, then > the resulting makefile would probably only be runnable by the script that > generated it, because that is also what set the environment variables. But > that should also be the case with UNIX. > > Or am I missing something here? I'm not quite following what you are proposing. I think I did something for macro propagation in Module::Build's compatibility mode, which might be worth a look. > Also, MMK/MMS should be able to use UNIX filename syntax, as long as every > file reference is in UNIX format. That should be able to simplify the work > in getting mm_vms to support the extended character set mode. Er, assuming major rewrites of MMK and/or MMS to handle Unix syntax filenames, which they currently don't handle at all.
Re: MM_VMS and File::Spec::VMS.pm intertanglement.
On Wed, Nov 12, 2008 at 10:13 PM, Michael G Schwern <[EMAIL PROTECTED]> wrote: > John E. Malmberg wrote: >> Putting a print STDERR statement shows that is not the case, that the >> methods of those names contained in File::Spec::VMS are used unless they >> are called by MM_VMS. > > The internal calls to eliminate_macros() and fixpath() should simply be > removed from File::Spec::VMS. They're only used to deal with make macros, its > a very MakeMaker specific thing. > > They were left in place so that new versions of File::Spec would continue to > work with older (pre 6.11 which is from perl 5.8.0 and older) versions of > MakeMaker. That was five and a half years ago. It's safe to remove them. Whether it's safe or not it's certainly worth a try. There are a *lot* more tests now for MM, File::Spec, and all the core modules that use File::Spec than there were five and half years ago, so if removing these breaks something I think we'd know pretty quickly.
Re: MM_VMS and File::Spec::VMS.pm intertanglement.
John E. Malmberg wrote: > Would there be an issue if File::Spec::VMS get the changes before MM_VMS? Dunno, what you're doing is all gibberish to me so far. I haven't touched MM_VMS in a while. December 2007 to be exact and Sept 2006 before that. Though this is curious... > Putting a print STDERR statement shows that is not the case, that the > methods of those names contained in File::Spec::VMS are used unless they > are called by MM_VMS. The internal calls to eliminate_macros() and fixpath() should simply be removed from File::Spec::VMS. They're only used to deal with make macros, its a very MakeMaker specific thing. They were left in place so that new versions of File::Spec would continue to work with older (pre 6.11 which is from perl 5.8.0 and older) versions of MakeMaker. That was five and a half years ago. It's safe to remove them. -- You know what the chain of command is? It's the chain I go get and beat you with 'til you understand who's in ruttin' command here. -- Jayne Cobb, "Firefly"
Re: MM_VMS and File::Spec::VMS.pm intertanglement.
Michael G Schwern wrote: John E. Malmberg wrote: The comments for eliminate_macros() and fixpath() in File::Spec::VMS imply that they are only used in older versions of Make Maker that does not contain them. Putting a print STDERR statement shows that is not the case, that the methods of those names contained in File::Spec::VMS are used unless they are called by MM_VMS. I am now trying to update File::Spec to handle VMS EFS character specifications and GNV (GNU is not VMS) Unix compatibilty mode, so I will need to first update File::Spec::VMS, and then MM_VMS later. In the EFS (Extended character set) mode, in addition to handling the extended character set, the routines will return Unix syntax for Unix input and VMS syntax for VMS input. For cases where there is no input, or the input does not indicate the output format, then the output will be in VMS syntax unless the UNIX compatibilty mode is also on. If that mode is on, then ambigous output will be in Unix syntax. This appears to match the expectation of most of the Perl scripts that I have worked on getting ported to VMS. Do you need anything, or was that just an FYI/RFC? Mostly a FYI/RFC. Would there be an issue if File::Spec::VMS get the changes before MM_VMS? The last time I did this with Perl 5.8.6/7, I just made the changes to get the tests to pass. This time I am trying to get the operations to be as correct as possible. So I need to re-write File::Spec::VMS so that in EFS mode it almost never calls vmsify or unixify, and I do not know how long that will take. -John [EMAIL PROTECTED] Personal Opinion Only
Re: MM_VMS and File::Spec::VMS.pm intertanglement.
John E. Malmberg wrote: > The comments for eliminate_macros() and fixpath() in File::Spec::VMS > imply that they are only used in older versions of Make Maker that does > not contain them. > > Putting a print STDERR statement shows that is not the case, that the > methods of those names contained in File::Spec::VMS are used unless they > are called by MM_VMS. > > I am now trying to update File::Spec to handle VMS EFS character > specifications and GNV (GNU is not VMS) Unix compatibilty mode, so I > will need to first update File::Spec::VMS, and then MM_VMS later. > > In the EFS (Extended character set) mode, in addition to handling the > extended character set, the routines will return Unix syntax for Unix > input and VMS syntax for VMS input. > > For cases where there is no input, or the input does not indicate the > output format, then the output will be in VMS syntax unless the UNIX > compatibilty mode is also on. If that mode is on, then ambigous output > will be in Unix syntax. > > This appears to match the expectation of most of the Perl scripts that I > have worked on getting ported to VMS. Do you need anything, or was that just an FYI/RFC? -- Robrt: People can't win Schwern: No, but they can riot after the game.
MM_VMS and File::Spec::VMS.pm intertanglement.
The comments for eliminate_macros() and fixpath() in File::Spec::VMS imply that they are only used in older versions of Make Maker that does not contain them. Putting a print STDERR statement shows that is not the case, that the methods of those names contained in File::Spec::VMS are used unless they are called by MM_VMS. I am now trying to update File::Spec to handle VMS EFS character specifications and GNV (GNU is not VMS) Unix compatibilty mode, so I will need to first update File::Spec::VMS, and then MM_VMS later. In the EFS (Extended character set) mode, in addition to handling the extended character set, the routines will return Unix syntax for Unix input and VMS syntax for VMS input. For cases where there is no input, or the input does not indicate the output format, then the output will be in VMS syntax unless the UNIX compatibilty mode is also on. If that mode is on, then ambigous output will be in Unix syntax. This appears to match the expectation of most of the Perl scripts that I have worked on getting ported to VMS. -John [EMAIL PROTECTED] Personal Opinion Only
