[BioLib-dev] Test Errors on Ubuntu

[Pjotr Prins]

On Thu, Feb 11, 2010 at 10:53:11PM -0600, Chris Fields wrote:
> One of the issues is that it appears the perl test script
> preferentially uses any installed staden_io_lib.so over any locally
> built one, or is only finding the library after it is installed.
> The missing libR.so triggered this; deleting the aforementioned
> library and running './configure --with-staden' works (no more
> libR.so needed).  We should probably set a 'use lib' directive in
> the script to preferentially catch local module builds.

Good. The problem is that we can not distinguish between installed
libs and later locally built ones. I can try and find a way for the
build system to use the local ones in the tree first, but that may
defeat the purpose - i.e. testing an installed system.

Now, what would be a good policy?

Also the naming. You can see I use versioning on the Clibs, but not
on the Perl module - as it finds itself by its name.

Maybe we can use different naming for the development tree - so the
tests would require 'staden_iolib-testing.pm'. I could copies at
build time which would not interfere with the main setup. I am not
sure about all the implications though.

But maybe it is better to specifically used LD_LIBRARY_PATH instead.
Leave overrides to the user. That gives more predictable behaviour.

Feel free to try some stuff and tell me what works for you.

> Setting LD_LIBRARY_PATH or adding to /etc/ld.so.conf.d fixes the
> problem. libR.so is in /usr/lib/R/lib, which apparently is not added
> to ld.so.conf.d via apt-get.

That is a bug, in my book. Debian does not do this. I suspect the
Ubuntu guys figure that only R uses that lib, and therefore knows
where to find it.

> I think this sorts out most pertinent issues.  I'm working on a
> simple BioPerl-specific set of modules for io_lib that will
> eventually replace the XS-based code from bioperl-ext.  This gets us
> along that path a bit.  Probably something to note for the install
> process, however.

Cool :-). Once that is done we can find a way to do that
automatically for other modules/libraries.

BTW I am half way done with automated documentation. We should be
able to generate POD files from SWIG fairly soon.

Pj.