You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are zillions of tools and modules created in the lifetime of perl that expect ..../lib/perl5 to exist. This will likely either change name to .../lib/perl7 (and perl8 …) or even .../lib/perl. We should acknowledge there existence and provide (new) tools to make that transition easy.
One example is the Configure option -Dinc_version_list. You can set it to none, which is what I always do, so there is no issue, but the default is to find pure-perl modules compiled for previous versions installed in the same tree. If that tree is now empty from the new language' point of view, it won't find the modules, even if they would work without problems.
FWIW, I think most Linux distributions use none for system-perl, which will show in Config as a single space:
$ perl -V:inc_version_list
inc_version_list=' ';
From INSTALL:
=head2 Disabling older versions of Perl
Configure will search for binary compatible versions of previously
installed perl binaries in the tree that is specified as target tree,
and these will be used as locations to search for modules by the perl
being built. The list of perl versions found will be put in the Configure
variable inc_version_list.
To disable this use of older perl modules, even completely valid pure
perl modules, you can specify to not include the paths found:
sh Configure -Dinc_version_list=none ...
If you do want to use modules from some previous perl versions, the
variable must contain a space separated list of directories under the
site_perl directory, and has to include architecture-dependent
directories separately, eg.
sh Configure -Dinc_version_list="5.16.0/x86_64-linux 5.16.0" ...
When using the newer perl, you can add these paths again in the
PERL5LIB environment variable or with perl's -I runtime option.
As a demo, I just compiled 5.26.2 from scratch, and it shows:
Note that the list is probably based on what is installed on the system perl is being built on, not on the system perl is installed on, which complicates matters a lot.
If perl7 (and perl8 and ...) are to support this too, we need a plan
The text was updated successfully, but these errors were encountered:
There are zillions of tools and modules created in the lifetime of perl that expect
..../lib/perl5
to exist. This will likely either change name to.../lib/perl7
(andperl8
…) or even.../lib/perl
. We should acknowledge there existence and provide (new) tools to make that transition easy.One example is the
Configure
option-Dinc_version_list
. You can set it tonone
, which is what I always do, so there is no issue, but the default is to find pure-perl modules compiled for previous versions installed in the same tree. If that tree is now empty from the new language' point of view, it won't find the modules, even if they would work without problems.FWIW, I think most Linux distributions use
none
for system-perl, which will show inConfig
as a single space:From
INSTALL
:As a demo, I just compiled 5.26.2 from scratch, and it shows:
Note that the list is probably based on what is installed on the system perl is being built on, not on the system perl is installed on, which complicates matters a lot.
If perl7 (and perl8 and ...) are to support this too, we need a plan
The text was updated successfully, but these errors were encountered: