Craig Berry wrote:
!Hmm. I can't see right off why they are important since after
!reading their descriptions I have no idea what they are for. I guess
!it wouldn't hurt to make installprefix the same as prefix, which is
!just C<perl_root>. The other two seem to have something to do with
!"add-on" pieces of some kind, though it is not clear from the
!documentation whether an add-on is a Perl extension, an external
!library used to build a Perl extension, or some external executable
!program used in conjunction with Perl or an extension. In the latter
!two cases, I can't see how I could (or would want to) specify their
!locations at configuration time. In the case of Perl extensions,
!there are lots of other config variables that already say where
!things should go (if there weren't, we couldn't have been installing
!extensions successfully for lo these many years).
!
!So, I'll be happy to doctor up configure.com when I know what should
!go there, but I'm not confident about guessing what that should be.
I would advise against doing any thing with installprefix, possibly
with the other /^install\w+/ variables as well. They are of use
primarily on Unix where you do not have binary relocatability
of perl (on non Unix, including VMS, we have binary relocatability).
Allow me to illustrate ala Unix how it is that installprefix could
prove useful. Suppose that I had a master build machine running
Linux or Tru64 or Solaris. On that machine I've installed a ton
of freeware things that have the *BSD derived tendency to autoconfigure
installations of things into /usr/local, hence my /usr/local/bin
is stuffed with dozens or perhaps hundreds of files. Suppose further
that I wanted to upgrade from perl 5.6.0 to perl 5.8.0 but not
alter anyone's $PATH to do so (i.e. I want it in /usr/local).
Suppose further that I have 2000 workstations on which I must push
out this change, but I'd rather not use rdist, pckg, rpm, deb, or
any of the other non-perl packaging/distribution systems.
If I were to run a build with:
sh Configure -Dprefix=/usr/local
make
make test
make install
What I would have is a mess of new perl stuff in /usr/local/{bin,lib,man}
but what I would prefer is a way to make the build toss the
install off into an otherwise unused directory such that I can tar it
up into a tar ball and then on my 2000 workstations the only thing
I have to do is untar the tarball (replete with binaries), edit
the Config.pm file to reflect the local uname and email addresses, then
move on to the next workstation. The way to do that is:
sh Configure -Dinstallprefix=/tmp/perl5.8.0 -Dprefix=/usr/local
make
make test
make install
cd /tmp/perl5.8.0
tar -cvf perl5.8.0.binary.tar .
then take the perl5.8.0binary.tar file to the various /usr/local's
and tar -xvf the file.
As you can see, with perl on VMS doing relative file lookups (@INC)
employing a rooted logical name there is no need for installprefix.
To have configure.com support installprefix imagine that
you wanted to run:
copy perl5_8_0.tar dka100:[000000]
set def dka100:[000000]
tar -xvf perl5_8_0.tar
set def [.perl5_8_0]
@configure "-Dinstallprefix=dka200:[perl5_8_0]" "
-Dprefix=dka300:[perl5_8_0.]" "-des"
mms
mms test
mms install
set def dka200:[000000]
backup [.perl5_8_0...] perl5_8_0.bck/save/log
copy perl5_8_0.bck dka300:[000000]
set def dka300:[000000]
backup perl5_8_0.bck/save [.perl5_8_0...]/log
So what did pre-installing perl onto the dka200: device buy
you on VMS? Absolutely nothing. You should have instead
configure the "-Dprefix=dka300:[perl5_8_0.]" and if later
you wanted to make a backup save set of the live perl_root
you could have. If you then wanted to move the perl_root to
another location you could, then redefine perl_root and
you are good to go. Note that VMS actually has an advantage
over the Unixoid installprefix way: with the installprefix
kit lying in e.g. /tmp/perl5.8.0 there is no way for me to
add CPAN modules to the kit. For example this will not
work:
/tmp/perl5.8.0/bin/perl Makefile.PL
since the Unix kit was Configured to have a prefix of /usr/local
it won't be able to find it's @INC goodies until after
the tar ball from /tmp/perl5.8.0 is unpacked into /usr/local
at which point you are back to the tedium of trying to pick the
perl bits out of /usr/local - should you goal be to distribute
not just perl 5.8.0 but a slew of CPAN modules as well to
your 2000 unix workstations.
N.B. None of these comments necessarily pertain to the
/^vendor\w+/ variables, or possibly even /^site\w+/.
Peter Prymmer
