[BioLib-dev] Test Errors on Ubuntu

[Chris Fields]

On Feb 11, 2010, at 11:21 PM, Pjotr Prins wrote:

> 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?

Well, it looks as if the other test scripts (emboss, example) do essentially what I described, adding the local directory first to @INC for perl:  

BEGIN{unshift(@INC, "../emboss")};
use biolib::emboss;

I can try seeing if that helps.

> 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.

Same thought here as well.  I'm using the R project's build, though; there have been reported problems with Canonical's R packages.  Regardless, it shouldn't be that hard to add the lib to ldconfig during installation.

>> 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.

Very nice! 

chris