[BioLib-dev] GSL
Pjotr Prins
pjotr.public14 at thebird.nl
Wed Aug 5 06:07:47 UTC 2009
On Tue, Aug 04, 2009 at 07:32:31PM -0400, Hilmar Lapp wrote:
> Hi Pjotr - many systems come pre-installed with GSL these days. Is it
> really wise not to just assume it as a system dependency?
>
> -hilmar
That is a call we have to make. There are two problems with these
type of dependencies:
(1) libraries change
(2) on different systems they are in different places
The main reason I like to have the source base inside biolib is that
when we do a release we have ONE source base. So bugs can be found,
without the added complexity of (1). Especially over time this is a
great concern. On the Perl mailing list you encountered that this
year with the staden_io_lib module - the interface changed. In
addition many installations are quite old, so you get an old GSL
library, or BOOST, or whatever.
With (2) is a particular concern since bio* developers are all over
the place: different distros of Linux, OSX, Cygwin, Windows. Having
the source tree in biolib kills those birds with one stone.
It is possible to use external dynamically linked libraries. We do
that for Rlib.so and zlib.so now (note that Biolib does not compile,
at this point, on Windows for that very reason).
The call is on us. I am not convinced the GSL is stable, Xin had to
add a symlink because one file was added in the last months, nor that it
is easily found on most systems. And the source base is not that big
(BOOST is ten times as big). We are mapping against these libraries -
also the GSL.
So in it goes, as far as I am concerned. If only for the fact the I
only want the latest and greatest :-)
With Biolib you will get a stable and modern set of tools to compile
against. In addition we use the latest and fastest versions of
dependent software. How do you think the bio* developers will like that?
Pj.
More information about the BioLib-dev
mailing list