[Bioc-devel] GSVA/configure.ac problem

dear core developers at BioC,

as you might have seen in a message at BioC, the package GSVA (which i
collaborate maintaining it) requires GSL version>= 1.6, however current
GSL version is 1.15 (see http://www.gnu.org/s/gsl) and in fact the
original version of the package we submitted required version>= 1.12

according to the svn log, the core development of BioC decided to
replace the configure.ac file by other one more appropriate for building
the package in windows and apple machines, so i guess that this 1.6
version requirement change might have been introduced at that point.

i must confess i'm not an expert with configure scripts, so i'd like to
double check with you whether i could solve this issue by simple
replacing all the 1.6 values by 1.12 values.

i currently cannot verify
whether that works because in fact the configure script seems to by pass
that requirement, but the message pops up when GSL is not available and
confuses the user about what GSL should be installed in the system.

additionally, our former configure script had the options

--with-gsl-lib
--with-gsl-include

in order to allow the user to have a non-system-wide installation of
GSL. i understand that this should be now handled differently to ensure
across-platform compatibility and it depends whether the gsl-config
script is on the PATH variable. would it be possible to add some option
to the configure script to tell where exactly the gsl-config script is??
(in case the user cannot or does not want to have a system-wide
installation of GSL).

thanks!!!!
robert.

Yes "the core development of BioC" (and in that case it was me) fixed
the configure script a couple of days before the release because it was
not working properly on our Mac OS X build machine. I must confess I'm
not an expert with configure scripts either so what I did was copy
the configure.ac file from another package that links to the GSL, and
did very minor modifications to it (if you do diff GSVA/configure.ac
flowClust/configure.ac you'll be surprised how little different those
files are). I forgot to replace >= 1.6 by >= 1.12 though, sorry.

That seems to work (I just tested this on my Linux laptop). Don't
forget to rerun autoconf.

Even for a non system-wide installation of GSL, the user can always
(and should) have the gsl-config script in his/her PATH. It's reasonable
to assume that if s/he was able to install his/her own private GSL, s/he
also knows how to modify his/her PATH to point to it. Alternatively, as
displayed by the error message above, s/he can set the environment
variable GSL_CONFIG to point to his/her private copy of
gsl-config. Does that make sense?

hi Herv?,

Yes "the core development of BioC" (and in that case it was me) fixed
the configure script a couple of days before the release because it was
not working properly on our Mac OS X build machine. I must confess I'm
not an expert with configure scripts either so what I did was copy
the configure.ac file from another package that links to the GSL, and
did very minor modifications to it (if you do diff GSVA/configure.ac
flowClust/configure.ac you'll be surprised how little different those
files are). I forgot to replace >= 1.6 by >= 1.12 though, sorry.

thanks a lot for fixing the configure script. I have found out in the
last days that in fact this "1.6" version might have to do with the
versioning standard of GSL for windows which according to this url:

http://gnuwin32.sourceforge.net/packages/gsl.htm

seems to follow an independent scale since it says that right now the
latest version is "1.8". so i've made the change in the devel-version of
GSVA but i'm afraid that it may not build anymore in windows. In such a
case I guess I would have to address that by updating the configure.ac
script such that if the system is unix then requires version >= 1.12 and
if it's windows then it requires version >= 1.6. I hope I don't have to
because at the moment I have no clue how I would do that.

next to this, in a recent post at BioC

https://stat.ethz.ch/pipermail/bioconductor/2011-November/042033.html

it was described an additional step that should be done to have a
successful windows installation of the GLAD package, which also requires
GSL, and which consists of duplicating the file libgsl.dll into a file
called libgsl-0.dll

i have verified in the windows xp partition of my mac, that this latter
step is absolutely necessary to have an installation of GSVA, and GLAD
too, without problems. so i wonder whether you had to do the same with
the GSL installation of your windows machines in Seattle, or you install
GSL in windows in some other way.

That seems to work (I just tested this on my Linux laptop). Don't
forget to rerun autoconf.

thanks, i've done just that and submitted the changes to devel. if i see
that the package builds and installs correctly i'll push them to
release.

Even for a non system-wide installation of GSL, the user can always
(and should) have the gsl-config script in his/her PATH. It's reasonable
to assume that if s/he was able to install his/her own private GSL, s/he
also knows how to modify his/her PATH to point to it. Alternatively, as
displayed by the error message above, s/he can set the environment
variable GSL_CONFIG to point to his/her private copy of
gsl-config. Does that make sense?

yes, you're right, thanks for clearing this up. I've also updated
accordingly the README file of the package.


cheers,
robert.

I can't say exactly where we got the GSL on our build machines. We
must have downloaded it at some point and I'm trying to find that
download, but so far without luck. I believe that we downloaded a
pre-compiled version of GSL for windows.

I can tell you that the version of GSL we are running on our windows
build machines is 1.13.

I don't think we copied libgsl.dll to libgsl-0.dll. In fact, in our
distribution of the GSL there is no libgsl.dll, only libgsl-0.dll, and
you can see by looking at the build reports that GSVA, GLAD, and other
packages using the GSL are building fine.

There are a couple of other things you need to do:
1) Set an environment variable called LIB_GSL that points to the root
of your GSL installation (on our build machines, C:/GSL (note forward
slash).
2) Make sure c:\GSL\i386\bin and c:\GSL\x64\bin are in your PATH.

Hope this helps,
Dan