automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Libtool, SWIG and testing


From: Guillaume Marcais
Subject: Re: Libtool, SWIG and testing
Date: Tue, 28 Jul 2015 11:58:22 -0400

On Sat, Jul 25, 2015 at 9:41 AM, Gavin Smith <address@hidden>
wrote:

>
> I'd suggest not hard-coding the name of the shared library in the Perl
> code. It could be extracted from the *.la file. That would likely
> improve portability. I don't see any way to avoid looking in .libs.
>
>
Thank you for your answer.

In this case, the Perl code that loads the shared library is generated by
SWIG (mummer.pm). It does use DynaLoader and calls "bootstrap mummer;". The
Makefile.am part that builds this library reads:

perlextdir = $(PERL_EXT_LIB)
perlext_SCRIPTS = perl5/mummer.pm
perlext_LTLIBRARIES = perl5/mummer.la
perl5_mummer_la_SOURCES = perl5/swig_wrap.cpp $(SWIG_SRC)

plus some other flags set in _CPPFLAGS, _LDFLAGS etc. Could really LIBTOOL
build a shared object in the .libs directory that could not be loaded by
"bootstrap mummer;"?

In other words, for testing, I would rather use the Perl code that is
generated by SWIG and that will ultimately will be installed, rather than
having to write my own loader. So far it seems to work by only tweaking the
environment with only the name ".libs" being really hard coded here. The
name of the library is coming from the Makefile.am (perl5/mummer.la).

Guillaume.



> There are other ways to affect Perl's module search path: by setting
> the PERL5LIB environmental variable, or by adding directories to @INC
> when the Perl program is run.
>
> I have a similar problem at the moment on a project. It doesn't use
> SWIG, but XS. (I know nothing about SWIG.) You can see the code at
>
> http://svn.savannah.gnu.org/viewvc/trunk/tp/Texinfo/Convert/XSParagraph/XSParagraph.pm?revision=6463&root=texinfo&view=markup
> . It uses the DynaLoader module to load a dynamic library file.
>
> See this recent discussion:
> https://lists.gnu.org/archive/html/automake/2015-06/msg00018.html and
> https://lists.gnu.org/archive/html/automake/2015-07/msg00002.html.
> Apparently this is a road not very well travelled, so there is no
> "proper way to do it".
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]