Alien
view release on metacpan or search on metacpan
possible
Or at least isolate the dynamic libraries so they can be used by FFI,
but do not use them to build XS modules. The reason for this is that
if an end user upgrades their version of Alien::Foo it may break the
already installed version of Foo::XS that used it when it was
installed.
On Windows (ActiveState, Strawberry Perl)
Many open source libraries use autoconf and other Unix focused tools
that may not be easily available to the native (non-Cygwin) windows
Perl. Alien::MSYS provides just enough of these tools for autoconf
and may be sufficient for some other build tools. Also, Alien::Build
and Alien::Base have hooks to detect autoconf and inject Alien::MSYS
as a requirement on Windows when it is needed.
MB vs EUMM
The original Alien documentation recommends the use of Module::Build
(MB), which at the time was recommended over ExtUtils::MakeMaker
lib/Alien.pm view on Meta::CPAN
=item When building from source code, build static libraries whenever possible
Or at least isolate the dynamic libraries so they can be used by FFI,
but do not use them to build XS modules. The reason for this is that if
an end user upgrades their version of C<Alien::Foo> it may break the
already installed version of C<Foo::XS> that used it when it was
installed.
=item On Windows (ActiveState, Strawberry Perl)
Many open source libraries use C<autoconf> and other Unix focused tools
that may not be easily available to the native (non-Cygwin) windows
Perl. L<Alien::MSYS> provides just enough of these tools for C<autoconf>
and may be sufficient for some other build tools. Also, L<Alien::Build>
and L<Alien::Base> have hooks to detect C<autoconf> and inject
L<Alien::MSYS> as a requirement on Windows when it is needed.
=item MB vs EUMM
The original Alien documentation recommends the use of L<Module::Build>
(MB), which at the time was recommended over L<ExtUtils::MakeMaker>
( run in 1.087 second using v1.01-cache-2.11-cpan-df04353d9ac )