add property alien_isolate_dynamic

[plicease]

This is my proposed solution for #11. It isolates the dynamic libraries into a separate directory so they will not be considered when creating XS modules. This is only done when alien_isolate_dynamic is set to true. For this to be useful, the author of a Alien::Foo module will need to build position independent code on platforms that require it, in which case also accepting #47 or something similar will be highly desirable.

There are a number of advantages to forcing static libraries when building XS modules:

1. upgrades to Alien::Foo will no longer break Foo::XS. The downside is that Foo::XS will still be using the old version of libfoo, but I believe this is better than breaking the module.
2. Alien::Foo is no longer a run time dep for Foo::XS (just a build dep) so there is less to load
3. The method that currently AB uses for including dynamic libraries in platform specific search paths is broken on some platforms, such as Solaris (Loading .so file from share directory does not work on Solaris #50) and Windows (add bin (if it exists) directory to PATH on win32 #32). Though this is probably solvable.

There are also risks, but given that this alien_isolate_dynamic is optional they seem to be minimal.

That being said I think there is an argument for making alien_isolate_dynamic true by default, if not immediately, then some time down the road. I think the number of Alien::Foo type dists that would benefit from this feature is probably larger than the number with risks.

[mohawk2]

Has this been tried on a couple of examples, and on Windows and Unix-like?

[plicease]

I tested it with Alien::FFI and Alien::Editline ... they are not on CPAN yet, I was developing them mostly as examples. They do the right thing on Linux and Windows.

[mohawk2]

Good enough for me: aye.

[zmughal]

Nice!

Looking at line 32 of lib/Alien/Editline.pm, I see that it suggests calling the ->dlls() method.

my($dll) = Alien::Editline->new->dlls;

This function isn't in Alien::Base yet, is it? If an easy interface like that is available, I would say merge this.

Merge: Aye.

[plicease]

@zmughal good catch. dlls is what I was using in Alien::Libarchive::Installer and friends and the doco for Alien::Editline and Alien::FFI are based on the Alien::Libarchive doco. But when I was working on Alien::Base I called it dynamic_lib for two reasons

1. I was thinking it matched the libs accessor better.
2. dlls sounds a little windowsish to me; not a terrible thing, but was going for more of a cross platform terminology.

Now that I write this though I think it should be dynamic_libs to match the libs accessor, and also because technically there might be multiple dynamic libraries from a project.

Preferences anyone?

[plicease]

Also I should write some documentation for the dynamic_libs sub

[zmughal]

I like dynamic_libs.

Aside: when I was making Alien::LibMagic, I actually had multiple .dlls on Windows: libgnurx was needed by libmagic to deal with missing POSIX functions. But I may spin out that to a separate Alien package.

[mohawk2]

I like dynamic_libs too.

[plicease]

Oops forgot to change name, but did so with this commit:

df7d78c