automake
[Top][All Lists]
Advanced

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

Re: Libtool, SWIG and testing


From: Gavin Smith
Subject: Re: Libtool, SWIG and testing
Date: Sat, 25 Jul 2015 14:41:49 +0100

On 24 July 2015 at 20:13, Guillaume Marcais <address@hidden> wrote:
> I am improving/writing a C++ project (called MUMmer) which creates a shared
> library with libtool. In the same project, I also create a SWIG binding to
> access in Perl some of the functionality of this shared library.
>
> Libtool creates the shared library in a hidden directory:
>
> .libs/libumdmummer.so
>
> The SWIG compilation creates a couple a files, a perl module file and a
> shared library:
>
> swig/perl5/mummer.pm
> swig/perl5/.libs/mummer.so
>
> The problem comes in when when I write tests in Perl. I need to add
> directories to the Perl lib path so that it finds the module and shared
> library, like this:
>
> perl -I ./swig/perl5 -I ./swig/perl5/.libs test.pl
>
> Passing the path './swig/perl5/.libs' seems very hackish and not portable.
> This path was not specified anywhere, libtools decided to hide files there
> on its own, and it feels like I should not use these files directly.

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.

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]