Front page | perl.perl5.porters |
Postings from April 2003
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 Prymmer
Thread Previous
|
Thread Next