[EMAIL PROTECTED] wrote:
> "Craig A. Berry" <[EMAIL PROTECTED]> writes:
> > I just tried to do an "mmk install" with 5.6.0 plus Charles Lane's patches
> > and mine. The first thing I noticed is that README.VMS is no longer correct
> > in saying that you can define PERL_ROOT and then do an install because the
> > install target runs PERL_SETUP.COM and overrides whatever you've defined it
> > to.
>
> Sure you can define PERL_ROOT...it just won't do anything for you :)
>
> > Having to know where you are going to install at configure time seems a
> > bit odd to me, but I guess it's easy enough to edit PERL_SETUP.COM later as
> > long as we tell folks that's what they have to do. I have a vague memory
> > this was discussed before but can't find where at the moment.
That is the way they do it on unix. The README.win32 also mentions hand
editing the appropriate Makefile to set the installation location before
you do the build on that platform(s). (I wrote a Configure.bat that'll
run on NT and uses vms/munchconfig.c to yank an edited win32/Makefile out
of a template so that one did not have to edit the Makefile ahead of time).
Documenting the idea of editing PERL_SETUP.COM before typing `mms install`
is certainly a good idea. FWIW the unix Configure script offers to pause
and allow you to put Configure in the background while you go and edit the
config.sh file. That is something we don't currently offer with
configure.com && subconfigure.com, but we should.
No doubt about it, the docs could use further tweaking. I hesitated to do so
because I wanted to ensure that the DCL was in place before doccing something
that did not work. Unfortunately 5.6.0 was released! We also need to add
writability tests into configure.com at the point where someone specifies
their preferred PERL_ROOT location.
I have also not had a chance to test accepting the default for PERL_ROOT
(it defaults to the build directory BTW) then typing `mms install`.
Has anyone run into trouble with that?
Peter Prymmer
> Yeah, I tried a "install" myself...just to see what it was like and to
> find out how sensitive the build/test/install stuff was on having PERL_ROOT
> defined, and if it would work with the VMSPIPE stuff. And it did indeed
> work for me.
>
> > After doing that edit myself, I get boatloads of the following errors:
> >
> > cp /perl_root/lib/VMS_AXP/5_6_0/CORE/
> > creating new version of /perl_root/lib/VMS_AXP/5_6_0/CORE/
> > Couldn't copy to /perl_root/lib/VMS_AXP/5_6_0/CORE/: invalid argument
> > chmod 444 /perl_root/lib/VMS_AXP/5_6_0/CORE/
> > Couldn't chmod 444 /perl_root/lib/VMS_AXP/5_6_0/CORE/: no such file or directory
> > installperl: not found at installperl line 650.
>
> For the copy, it looks like it was trying to create "core.dir;2" and
> failed. Was there already a directory tree in place and you were
> installing over it?
>
> It's also a bit suspicious having the trailing slashes...that's
> generally an error for VMS, we catch it for chdir() calls IIRC, but
> maybe not other places.
>
> > Then it helpfully tells me both "Installation complete" and
> > "%MMK-I-ACTNOUPD, action did not update target INSTALL." I got the same
> > thing running with BYPASS so I know it's not a file protection issue. The
> > directory in question exists. My guess would be the file copy is in a
> > subprocess of a subprocess and has somehow lost track of the perl_root logical.
>
> Doubt it, lots more stuff would break if PERL_ROOT wasn't being inherited.
BTW I just recently noted that with:
DEC C V5.3-006 on OpenVMS VAX V6.2
that perl's chdir("/unix/style/spec/") will not work but that
chdir("vms:[style.spec]") will. Hence File::Find is fubarred.
(Though this was primarily with perl 5.005_02).
Peter Prymmer
