I have installed Perl 5.10 via FreeBSD Ports & modules that I use (system wide). Few days ago I also installed Perl 5.12 RC2 in my own user directory. After installing a module (and optional dependecies) not availble yet via FreeBSD ports with perl 5.12, I was thinking of installing pure perl modules in a tree separate from the ones which need to be compiled.

Point would be to share pure perl modules as much as possible, and avoid duplicate or reinstall among various perl versions as far as possible. My query in that regard is is there a way to distinguish a module (between a pure perl or compiled one) via cpan(plus) or during "perl (MakeFile|Build).pl .. (make|Build) install"?

Having different trees might not work out too well while automatically installing witin cpan(plus) as the initial tree might be set to the appropriate type based on the primary module, but not for subsequent dependencies. Seems like, cpan itself would need to be changed to accommodate the scenario.

If there are other suggestions to have separate version independent trees (of pure perl modules in one, compiled, version specific in another), I am all ears.

I was thinking of installing pure perl modules in a tree separate from the ones which need to be compiled.

You can instruct Perl's builder to add the lib directories of other Perl installations to the list from which @INC is initialised. Pure Perl modules will work fine, XS modules will give an error.

Point would be to share pure perl modules as much as possible, and avoid duplicate or reinstall among various perl versions as far as possible.

How do you know those pure Perl modules have no XS dependencies, and how do you know those pure Perl modules and their dependencies work unmodified on newer versions of Perl 5?

I personally care about only of those pure perl (call it "pp") modules which would continue to work with changing supporting software to a large extent, barring API changes. I am under no illusion that pp modules would not need to be ever updated to follow supporting software. If a otherwise pp module follows very closely changes in supporting modules, then it could go in the "perl-verison" directory along with rest of the lot.

Those concern are for later|never term, for me; I still do not know how to differentiate module type programmatically.

Putting the issue other way, would this be workable (to avoid manual work of module installation via any method among package manager, cpan, "perl Makefile.PL", etc.) ...

• programmatically generate list of modules in old version;
• install new perl;
• programmatically generate difference list from modules in new perl (in core, I suppose) & previous list;
• install modules from the difference list

... ?

Modules that aren't part of the core system are (unless overridden) installed in $LIBDIR/site_perl/<perl-version>/. Vendor (Linux distros for instances) supplied modules ought to go into $LIBDIR/vendor/<perl-version>. Core modules go into $LIBDIR/<perl-version>.

(I should have noted that I understand the default directory tree structure.) Yes, that <perl-version> is what I am trying to avoid, so that when 5.13 would come around, 5.12 directory would be blown away & pure perl modules remain unaffected installed outside of <perl-version> directory.

Indeed, you're right on target. The modules that I've had trouble with, as ikegami pointed out, are those that are not 'pure Perl'. I have quite a few non-pure-Perl modules.

Thanks, JavaFan. I really appreciate the response.