On Mon, 12 Feb 2001, Craig A. Berry wrote:
> At 3:52 PM -0800 2/12/01, Peter Prymmer wrote:
> >There are four documents since the [.porting]glossary. document also
> >gives information on what various OS and C RTL variables imply (as well as
> >the comments within config_h.SH).
>
> Thanks, Peter. There's now so much documentation we need
> documentation to navigate the documentation, or at least *I* do.
> Then again, I can always ask you when I get stuck :-).
Heh.
> > we do
> >not check to see if someone said:
> >
> > @configure "[EMAIL PROTECTED]"
>
> Hmm. That's what I thought.
We can patch that of course - but it won't do any good to folks who are
not building from source.
> >But that is actually a build time issue - for installation you want to
> >edit the values in Config.pm in you installed PERL_ROOT. Folks can still
> >do that if they like. The intricacies of setting ones Config.pm properly
> >is one of the big arguments in favor of building perl yourself from
> >source.
>
> Agreed. I suppose one could also edit config.h after configuring and
> before building. But I'm looking for ways to productionize the
> creation of pre-built kits since there seems to be some interest in
> that and those with unusual hardware/software environments are not
> always those well-versed in customizing a Perl configuration.
I understand and appreciate what you are trying to do. Note that one of
the recent big changes to perl on Unix was the ability to do:
sh Configure -Dinstallprefix=/some/path $other_args
where among other_args you can say -Dprefix=/opt/perl5 (or what have you)
What that does is when you execute the build step:
make install
it puts your perl installation tree into /some/path - thereby making it
_much_ easier to tar it up and not pick up any non-perl installation files
and you can then untar the tape archive into /opt/perl or /usr/local or
whereever you set your prefix to. The big disadvantage of that is that
the perl that gets installed into /some/path has $prefix as the root of
all the @INC entries so among other things it cannot find its own
MakeMaker hence it cannot be added to with external modules easily.
On VMS we simply have to define and redefine PERL_ROOT to play the
shenanigans that $installprefix only just recently addded to Unix perl.
In that respect we have it much easier than the Unix folk.
All of which may be beside the point you expressed: binary installations
for VMS. Unfortunately there does not exist an authoritative list of
those Config.pm variables that ought to be changed to relocate a perl
binary. In large part because the list is dynamic and platform dependent.
If it is any consolatin Jarkko H. has stated that he would prefer that
more of Config.pm is dynamically generated. The disadvantage of such a
scheme is that Config.pm would become even slower to load since syscalls
of various sorts would be triggered for any script that had a C<use
Config;> statement in it. Fortunately the majority of perl scripts that
have C<use Config;> in them are Makefile.PL's that need not perform
blisteringly fast.
As far as practical solutions I guess I'd recommend having a pre-release
party for whatever binary distribution scheme you come up with: if we on
vmsperl can gather enough tuits we might be able to spot (ideally fix) any
trouble spots, module building glitches etc that might arise.
Peter Prymmer
