Hello,
GSL provides a tool gsl-config to facilitate finding its install location etc. I have been using the attached patch on OSX to automatically find gsl libs and headers. I think it can be extended to any system that gsl-config is available. This will free user from the nightmare of installing gsl to a non-standard location.
Leo
Leo,
This looks suspiciously like pkg-config, which I have found to be wrong for ordinary Debian package installs. So what happens if gsl-config isn't found or is wrong? Does it fail to install GSLL?
If we're going to call out for something, how about "locate"? It always seems to work for me.
locate /libgsl.so.0
/home/liam/mathematics/gsl-1.11/.libs/libgsl.so.0 /home/liam/mathematics/gsl-1.11/.libs/libgsl.so.0.12.0 /usr/lib/libgsl.so.0 /usr/lib/libgsl.so.0.12.0 /var/chroot/sid-ia32/usr/lib/libgsl.so.0 /var/chroot/sid-ia32/usr/lib/libgsl.so.0.13.0
Then we have the problem of which one to choose, which is the preferred one? Maybe we could sort this by the preference rules similar to what Mirko gave (say /home first, /usr/local second, /usr/lib third -- but what if you just use your home dir for a build area and don't want it included, as I do?).
Does this work for everyone (at least on unix-like systems)? For that matter, for those of you that have multiple GSL libraries, does gsl-config get all of them, and in your preferred order?
As you can tell, I'm quite leery of changing anything in the include or library paths, based on my experience that anytime anything is changed, some platform/os/implementation gets left out in the cold. Given that I can only test the ones I have, I have to wait for someone to complain, and that may be quite a while.
Liam
On Thu, Apr 22, 2010 at 10:17 AM, Leo sdl.web@gmail.com wrote:
Hello,
GSL provides a tool gsl-config to facilitate finding its install location etc. I have been using the attached patch on OSX to automatically find gsl libs and headers. I think it can be extended to any system that gsl-config is available. This will free user from the nightmare of installing gsl to a non-standard location.
Leo
Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
On 2010-05-23 03:22 +0100, Liam Healy wrote:
Leo,
This looks suspiciously like pkg-config, which I have found to be wrong for ordinary Debian package installs. So what happens if gsl-config isn't found or is wrong? Does it fail to install GSLL?
If we're going to call out for something, how about "locate"? It always seems to work for me.
gsl-config takes the information when the lib is being built. That means it is only correct with the corresponding lib.
If a user have multiple installations of gsl and changes gsl-config to, for example, gsl-config-1.3 and gsl-config-1.4 and want to use 1.4, he or she needs sym link gsl-config to gsl-config-1.4.
Locate is only usable when it has the database. If not, one would get this: 'default database: `/var/db/locate.database' or $LOCATE_PATH'.
Best wishes, Leo
OK I've done two things, partially using your changes. In an abundance of caution, I've done this on a new branch "paths" so that we can test it out before committing to master.
1) Relying on CFFI's statement that library paths should be known already, I have eliminated them all: "Most, if not all, Lisps supported by CFFI have a reasonable default search algorithm for foreign libraries." 2) I have incorporated your suggestion to use gsl-config for the header files only. The use of cc-flags was only in effect for Macs as it was, and that is still the case.
This works correctly on linux (Debian) but it's important for people on other platforms to checkout the paths branch and test it, particularly those using Macs and cygwin.
git fetch git checkout -b paths origin/paths
Liam
On Sun, May 23, 2010 at 3:58 AM, Leo sdl.web@gmail.com wrote:
On 2010-05-23 03:22 +0100, Liam Healy wrote:
Leo,
This looks suspiciously like pkg-config, which I have found to be wrong for ordinary Debian package installs. So what happens if gsl-config isn't found or is wrong? Does it fail to install GSLL?
If we're going to call out for something, how about "locate"? It always seems to work for me.
gsl-config takes the information when the lib is being built. That means it is only correct with the corresponding lib.
If a user have multiple installations of gsl and changes gsl-config to, for example, gsl-config-1.3 and gsl-config-1.4 and want to use 1.4, he or she needs sym link gsl-config to gsl-config-1.4.
Locate is only usable when it has the database. If not, one would get this: 'default database: `/var/db/locate.database' or $LOCATE_PATH'.
Best wishes, Leo
-- CCL-USER> (if you fail to plan (plan to fail))
Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel