[XML-SIG] saxlib, xml, _xmlplus, etc.

[Mark D. Anderson]

> How does that work? Are these other perls also using perl56.dll? If
> they had been using, say, perl55.dll, are the binary modules not
> linked with perl55.dll? If they are, how does perl manage to use
> perl56.dll and perl55.dll simultaneously?

it just works because perl hasn't changed for a while. they are all using perl56.
in retrospect, i do think perl and python are not that much different here.
i can't compare how much functionality perl chose to insert in the 5.6 patch series
as compared to python 2.0 patch series.

> So you are saying that different perl versions share the same toplevel
> lib directory, but do not share any library files? Why is that a good
> thing?

perl has a lib/site_perl hierarchy and a lib hierarchy. both are searched, and both
may be updated using cpan.
nominally, the lib hierarchy is for modules that come bundled with the perl distro, and
site/lib is for ones that are add-ons, although this isn't entirely true for reasons probably having
to do with activestate. (yes, site_perl is located inside lib, but pretend that isn't true).

in both cases, all modules embed the perl version in their path, and for binary modules
(but not pure perl modules), the OS name is also embedded.
here is an excerpt from a perl-5.6 installation on linux.

./lib/5.6.0/CGI.pm
./lib/5.6.0/CPAN.pm

./lib/5.6.0/i686-linux/Data/Dumper.pm
./lib/5.6.0/i686-linux/auto/Data/Dumper/Dumper.so

./lib/site_perl/5.6.0/URI/file/Base.pm
./lib/site_perl/5.6.0/URI/file/Unix.pm

./lib/site_perl/5.6.0/i686-linux/SQL/Statement.pm
./lib/site_perl/5.6.0/i686-linux/Storable.pm

./lib/site_perl/5.6.0/i686-linux/auto/Storable/Storable.so
./lib/site_perl/5.6.0/i686-linux/auto/SQL/Statement/Statement.so

the separation of "lib" from "lib/site_perl" lets you separately upgrade (or rollback) your perl distribution
from whatever site-specific addons you have.
the embedding of the OS name allows you to overlay multiple operating systems in your site_perl
area (say, hpux, linux, and freebsd) for a single perl version, which may be convenient either
for a single developer or multiple developers sharing a mounted install.
by default, perl of some version X will attempt to load the module in the version directory
which is most recent but not more recent than X. So a 5.6.0 perl would attempt to load a 5.005
module if there was none in the 5.6.0 tree, but a 5.005 perl would ignore all 5.6.0 modules.
In some cases, a binary module (or even a pure-perl module) might not be compatible with
a newer perl. In that case, this algorithm would cause a runtime failure. The solution
is to either make a change in the configuration for the perl, or to simply install a more recent module
for that perl.

this was a change from pre-5.6, and remains poorly documented.
the best discussion is probably "Coexistence with earlier versions of perl5" in the INSTALL file.
it also has its limitations; for example a person could build the same version of perl ("5.6.0")
in multiple ways (say with threads and sfio) and probably get into trouble if some modules were shared.

note that at the perl source level, perl has other versioning facilities.
perl allows any program to require a minimum perl core version ("require 5.005").
you can also require a minimum version from any module being imported (assuming that module exports
a version, for example "use XML::Simple qw(1.04)".
the request for a particular minimum version of a module has no affect on the search, but
will abort if the search doesn't find one desired.

with my limited python experience i haven't yet seen analogous abilities to declare an assumed
python core version, or require a minimum version from another module.
but i realize the purpose of this mailing list is not to educate me in python :).

-mda