On Tue, 30 Jun 2015, Gavin Smith wrote:
Hello all,
I wonder if anyone could give pointers to advice on how to integrate a
Perl XS module with an Automake build system? Over at the Texinfo
project we're starting to replace parts of makeinfo with loadable
native-code modules, for speed.
The problem is that the Makefiles produced by ExtUtils::MakeMaker (the
module used by the XS tutorial, "man perlxstut") doesn't follow the
standards required by Automake. (Info node "(automake)Third-Party
Makefiles", and the GNU Coding Standards). For example, "make clean"
actually removes the Makefile.
In addition to behavior issues, a major problem is that the re-link
capabilities offered by libtool are not available. If one links from
the Perl module to a shared library in the build tree, then there is
the risk of continued reference to the build tree after installation
(a security/reliability issue) and the module might not even run.
The Perl test suite is likely to use the wrong shared libraries while
testing due to GNU/Linux's strong preference to using
already-installed libraries cached by 'ldconfig'. Due to this, I
changed GraphicsMagick so that it only links its Perl module at 'make
install' and time it uses the already-installed shared library. This
still does not help with DESTDIR installs.
After I made this change, some GNU/Linux distributions stopped
building the GraphicsMagick Perl module at all due to claiming that
the build is "broken". They expect that everything builds in tree in
one step and that 'make check' works as one would expect. I don't
think that this is possible to accomplish in a portable way using
ExtUtils::MakeMaker.
If there is a viable solution which avoids ExtUtils::MakeMaker and
allows Automake to drive behavior, with linkage managed by libtool,
then I am all ears.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/