view release on metacpan or  search on metacpan

lib/Alien/Base/Dino.pm  view on Meta::CPAN

  }
  
  @dir;
}


require "Alien/Base/Dino/$^O.pm";

1;

__END__

=pod

=encoding UTF-8

=head1 NAME

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

=head1 VERSION

version 0.01

=head1 SYNOPSIS

In your L<alienfile>:

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

Then instead of subclassing L<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;

=head1 DESCRIPTION

Every now and then someone will ask me why thus and such L<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 
B<building> dynamic libraries for an L<Alien> B<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 B<share> install?

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

=over 4

=item Your Alien becomes a run-time dependency.

When you link your C<Foo::XS> module with a static library from 
C<Alien::libfoo> it gets added into the DLL or C<.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 C<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 L<Alien::Build> and the alien C<Alien::libfoo> with extra 
dependencies during runtime.  Normally you wouldn't need those packages 
installed for end-user use.

=item Upgrades can and will break your XS module.

Again, when C<Alien::libfoo> builds a static library and it gets linked 
into a DLL or C<.so> for C<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 
C<Alien::libfoo> and it replaces the DLL or C<.so> file with an 
incompatible API or ABI?  Now your C<Foo::XS> module has stopped 
working!

=item 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