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:[000000.$(FOO)] which would expand to perl_root:[000000.[.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.
