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