Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re: Re: Installing (lotsa) modules

by Fletch (Chancellor)
on Oct 11, 2001 at 20:17 UTC ( #118256=note: print w/replies, xml ) Need Help??


in reply to Re: Installing (lotsa) modules
in thread Installing (lotsa) modules

You can also create your own bundles, or if you have a box that's already got what you want installed you can use the autobundle command to get CPAN.pm to make one for you using what's currently installed. See the section "POPULATE AN INSTALLATION WITH LOTS OF MODULES" in perldoc CPAN.

Replies are listed 'Best First'.
Re^3: Installing (lotsa) modules
by Bod (Chaplain) on Jan 24, 2021 at 21:33 UTC
    You can also create your own bundles

    Would modules that are not pure Perl still need a working compiler on the target machine? Or could they be complied on the donor machine and bundled onto the target machine fully formed?

      Would modules that are not pure Perl still need a working compiler on the target machine?

      Sure. All that a bundle does is to depend on a lot of other packages (those listed in the bundle), and so CPAN.pm just installs the dependencies as usual.

      Or could they be complied on the donor machine and bundled onto the target machine fully formed?

      Yes and no. Usually no, except when you build an entire distribution or when "donor" and target machine run exactly identical software. "Binary" modules (those using XS) usually not only depend on the exact perl version and its configuration, but usually also on the exact library versions they were linked against, and on their configurations. So if you can make perl and all libraries on the target the same as on the "donor" machine, copying will very likely work.

      If you look at any binary Linux distribution (e.g. Debian, Redhat, Ubuntu, Slackware), you can see why they can distribute compiled perl modules: The distribution development team controls compiler, libraries, perl, and perl modules, both versions and configurations. The packaging system has its own way of dependency tracking, and takes care of either updating a perl package after a library was updated, or keeping an old version of the library around for a perl package.

      Alexander

      --
      Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
        "Binary" modules (those using XS) usually not only depend on the exact perl version and its configuration

        Interestingly, I think "exact perl version" slightly overstates the condition.
        AFAIK, a package built for perl-5.x.y will be fine with perl-5.a.b, so long as x == a. (But no need for y == b. However, I can't recall if there was also a need for y <= b. Anyone ? )
        This meant, for example, that having built a Windows PPM package of a perl module for (say) perl-5.30.0, that same binary package would be fine for all 5.30.* versions of perl on Windows - so long as all of these perl-5.30.* versions had been configured the same.

        At least, that's the way it used to be - but I haven't tested to see whether the XS handshake tests that were added a couple of years ago might now interfere with that capability.
        If they do interfere, then they do so for no valid reason that I know of.

        Cheers,
        Rob

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://118256]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (3)
As of 2021-06-15 04:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What does the "s" stand for in "perls"? (Whence perls)












    Results (66 votes). Check out past polls.

    Notices?