Brad Hughes asked in response to a question I posed: !> Do you want to retain the ability to run the source tree as your PERL_ROOT !> or would it be OK to break that? Is this destined for 5.8.1 or later? ! !Why break this? I have many "installed" perls, choosable via on-the-fly !redefinition, at process, job, or group levels, of PERL_ROOT. The breakage might come about as accidental fallout of the change to vms/descrip_mms.template. As Craig pointed out it might be possible to fix the breakage using an aggregate copy (on VMS we'd use BACKUP, on Unix they could get away with "cp *.h" but the Unix Makefile does not provide for two possible installation destinations only one). The ability to switch between perl installations via a redefinition of PERL_ROOT would not be altered at all by the proposed changes to vms/descrip_mms.template so far as I understand them. !Actually, I've never understood the purpose of a separate "install" directory, !especially with disk space so cheap. Is it so you don't have to rebuild As you yourself have pointed out disk space is cheap hence a separate installation directory does not come at such a great expense. I think that in Perl's case there used to be an actual need to have a separate installation tree owing to the manner in which older MakeMaker's would create extensions - inifinite recursion in a File::Find type operation would occur if you attempted to add extension Foo::Bar from CPAN by unpacking it under your $Config{'prefix'}. AFAIK it is still recommended practice to not unpack extra module or extension distributions into your $Config{'prefix'}. Consider running: perl Makefile.PL make make test suppose that at that point that so many tests fail that you then realize that installation of the module is not possible (not without further config work, porting to your platform, what have you). If you were unfortunate enough to have unpacked it under your $Config{'prefix'} and someone noticed the Bar.pm file lying in directory Foo then they might assume that it is installed and working and start writing scripts that have C<use Foo::Bar;> statements in them and also start filing bug reports that "Module Foo::Bar; is broken". !and reinstall noncore modules? Wouldn't one *want* to rebuild, retest and !reinstall noncore modules with a new build of perl, especially in production !environments? I actually require it. As does everyone who manages a perl installation. On VMS we actually support simultaneous "installation" into two separate places: the place where you unpacked the perl source tar ball, and the place where either you or configure.com specified to become your PERL_ROOT. In addition PERL_ROOT is fully relocatable within the file system. One problem with the support of running perl.exe from the source unpacking location is the mishandling of files such as the many *.h files. Note that a h2xs.com extracted out of [.utils]h2xs.PL along with MakeMaker has a very different idea about where to find #include "perl.h" than does a build where perl.h is sitting only in perl_root:[000000]. In order to support installing perl into the place where you built it you can do so now such that if you ordinarily configure your build with: set def DKA100:[PERL-5_8_0] @configure "-des" mmk mmk test But you then omit running "mmk install" and modify the generated perl_setup.com to point to DKA100:[PERL-5_8_0.] (instead of the default of DKA100:[PERl-5_8_0_ROOT.] ) you should instead run the configuration and build like so: set def DKA100:[PERL-5_8_0] @configure "-Dprefix=DKA100:[PERL-5_8_0.]" "-des" mmk mmk test mmk install That is the "mmk install" step would be required if the needed BACKUP *.H "fixes" to descrip.mms cannot be worked out. I'd go so far as to say that the appendage of the "_ROOT" in configure.com could be done away with so that your preferrred style of installation would not require the "-Dprefix" specification. The need to run "mmk install" may or may not go away. Peter PrymmerThread Previous | Thread Next