view release on metacpan or  search on metacpan

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

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 
platforms.  Even on Windows which likes to be different, static 
libraries are essentially the same as on Unix.

=back

So all that said, why have I written this module, which provides support 
for dynamic libraries?  Well, maybe I am wrong, maybe it isn't that 

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

=head1 HOW

How does it work?  Use the bundled L<alienfile> plugin 
L<Alien::Build::Plugin::Gather::Dino>.  That will find any dynamic 
library paths in your share directory in case they are needed at 
runtime.  Then use L<Alien::Base::Dino> instead of L<Alien::Base> as the 
base class for your L<Alien> module.  Instead of using L<XSLoader> or 
L<DynaLoader> to load your XS module, use the C<xs_load> from your 
L<Alien>.  Hopefully the synopsis above makes it clear.

=head1 ETYMOLOGY

This module is named B<Dino> being short for Dinosaur.  I really like 
Dinosaurs (also friendly crocodiles and L<platypuses|FFI::Platypus> in 
case you hadn't noticed).  "Dino" also has a similar sound to "Dyna" 
which is frequently used as a short name or prefix meaning "dynamic".  I 
didn't want to call it "Dyna" or "Dynamic" since it is only building a 
dynamic library for share installs.  I didn't want to call it DynaShare 
because that was getting a bit wordy.  So Dino.

=head1 BASE CLASS

This class is a subclass of L<Alien::Base> and as such, in inherits all
of its methods and properties.

=head1 METHODS

=head2 xs_load

 $alien->xs_load($package, $version);
 $alien->xs_load($package, $version, @other_dino_aliens);

=head2 rpath

 my @dirs = $alien->rpath;

Returns the list of directories that have non-system dynamic libraries
in them.  On some systems this is needed at compile time, on others
it is needed at run time.

=head2 libs

 my $libs = $alien->libs;

On some platforms, this subclass overrides the behavior of the C<libs> method.

=head1 CAVEATS

Lots.  In summary:

=over 4

=item Your Alien is a run-time dependency and you will annoy system integrators

=item Your XS can be broken by upgrades to your Alien

=item Your platform may not be supported

=back

Also, this module should start with the caveat section and then go from 
there.  Most modules I write are not like that.

These platforms seem to work: Linux, OS X, Windows, Cygwin, FreeBSD, 
NetBSD, OpenBSD, Debian kFreeBSD.

Currently has L<Alien::Autotools> as a prerequisite.  I hope to remove that prereq
asap.

=head1 SEE ALSO

=over 4

=item L<alienfile>

=item L<Alien::Base>

=item L<Alien::Build>

=item L<Alien::Build::Plugin::Gather::Dino>

=back

=head1 AUTHOR

Graham Ollis <plicease@cpan.org>

=head1 COPYRIGHT AND LICENSE

This software is copyright (c) 2017 by Graham Ollis.

This is free software; you can redistribute it and/or modify it under
the same terms as the Perl 5 programming language system itself.

=cut