view release on metacpan or  search on metacpan

README  view on Meta::CPAN

NAME

    Alien::Base::Dino - Experimental support for dynamic share Alien
    install

VERSION

    version 0.01

SYNOPSIS

    In your alienfile:

     use alienfile;
     
     share {
       ...
       plugin 'Gather::Dino';
     }

    Then instead of subclassing Alien::Base:

     package Alien::libfoo;
     
     use base qw( Alien::Base::Dino );
     
     1;

    And finally from the .pm side of your XS module:

     package Foo::XS;
     
     use Alien::libfoo;
     
     our $VERSION = '1.00';
     
     # Note caveat: your Alien is now a run-time
     # dependency of your XS module.
     Alien::libfoo->xs_load(__PACKAGE__, $VERSION);
     
     1;

DESCRIPTION

    Every now and then someone will ask me why thus and such Alien thing
    doesn't work with a dynamic library error. My usual response is can you
    make it work with static libraries? The reason for this is that
    building dynamic libraries for an Alien share install introduce a
    number of challenges, and honestly I don't see the point of using them,
    if you can avoid it. So far I haven't actually seen a situation where
    it couldn't be avoided. Just to be clear: dynamic libraries are fine
    for Alien, and in fact desirable when you are using the system provided
    libraries. You get the patches and security fixes supplied by your
    operating system.

    Okay, so why not build a dynamic library for a share install?

    For this discussion, say you have an alienized library Alien::libfoo
    and an XS module that uses it called Foo::XS (as illustrated in the
    synopsis above).

    Your Alien becomes a run-time dependency.

      When you link your Foo::XS module with a static library from
      Alien::libfoo it gets added into the DLL or .so file that the Perl
      toolchain produces. That means when you later use it, it doesn't need
      anything else. When you try to do the same thing with a dynamic
      library, you need that dynamic library, which is stored in a share
      directory of Alien::libfoo.

      For people who install out of CPAN this is probably not a big deal,
      but for operating system vendors (the people who integrate Perl
      modules into their operating system), it is a hassle because now you
      need this big build tool Alien::Build and the alien Alien::libfoo
      with extra dependencies during runtime. Normally you wouldn't need
      those packages installed for end-user use.

    Upgrades can and will break your XS module.

      Again, when Alien::libfoo builds a static library and it gets linked
      into a DLL or .so for Foo::XS, it doesn't need the original library
      anymore. If you are using a dynamic library and you do the same thing
      it maybe works today, but say tomorrow you upgrade Alien::libfoo and
      it replaces the DLL or .so file with an incompatible API or ABI? Now
      your Foo::XS module has stopped working!

    Dynamic libraries are not portable

      Dynamic libraries are widely supported on most modern operating
      systems, but each system provides a different interface. For example,
      Linux, Windows and OS X all have an environment variable that allows
      you to alter the search path for finding dynamic libraries, but all
      three have different extensions for dynamic libraries (OS X even has
      two!), the environment variables are called something different, and
      WHEN you can change them is different.

      The Perl core has code for loading dynamic libraries as part of its
      XS system on all platforms where you can build XS extensions
      dynamically. Unfortunately that code isn't quite reusable for use by
      Alien. Alien developers have limited time and access to many
      platforms, which means that many platforms will probably never get
      Alien support.

      Static libraries on the other hand pretty much work the same on all
      platforms. Even on Windows which likes to be different, static
      libraries are essentially the same as on Unix.