Michael Schwern wrote in response to me:
!> By the way, will the MakeMaker re-write support
!> building of CPAN modules to a perl that has been
!> `make install`ed into its $Config{'installprefix'} or
!> will it still complain about not being able to find
!> Config.pm, ExtUtuils::MM_Unix.pm et alia?
!
!I have absolutely no idea (what you're talking about|if it has been
!fixed).
In the perl guts it might be possible to make @INC
a bit more flexible. Among other things the port
to Windows allocates more than enough memory for
the "fixed" char strings to allow for relocating
a perl installation in such a way that perl.exe
on Windows can re-init it's @INC every time it is
run.
Similar things can be done on Unix, although the
portability of such constructs over the myriad
implementations of argv[0] return values can put
a hamper in the effort (not to even get into
the security implications: a fixed @INC set by
the root user should be intrinsically more trusted
than a dynamic one).
Within perl programming space I could imagine
optionally loading a C<use lib $Config{'installprefix'};>
type of subset to overcome the current inability
to add to an installprefix installed perl kit.
That would be the goal: allow unix admins to
create custom perl kits by them selves using only
sh, make, and possibly perl and tar.
VMS does not need to participate in any of this.
Since @INC is written in terms of a rooted logical
name (unless you really edit your config.sh that is)
it has no need to have an installprefix, but if
it helps you avoid calling C<defined($Config{'installprefix'}>
from within perl then we could add the redundant info
to the VMS configure process. Of course we'll pay
the penalty of bigger files and longer load times,
but it is only a small handful of redundant variables
used to appease unix - isn't it?
Peter Prymmer
