On Wed, Jun 24, 2009 at 2:52 PM, Zachelzacho@gmail.com wrote:

On Tue, Jun 23, 2009 at 8:05 PM, Liam Healy lhealy@common-lisp.net wrote:

...

Simply put, CFFI-grovel doesn't "think to look" anywhere, it looks where the application author (me, in the case of GSLL) tells it.

I think that maybe it (CFFI-grovel) should.  I'll try to justify this at the end.

...

I put the #+darwin conditional in libffi-unix.lisp based on a Mac-using colleague's report that he found ffi.h in ffi/ffi.h (sorry I don't know the full path).  That clause works for him.  I understand that people can install from Darwin ports, fink, etc., but libffi in particular is an Apple standard library so I used the location Apple seems to use.

That is weird.  Is this something new in, maybe in 10.5?

I want to emphasize: I have utterly no idea. All I know is my colleague claims he didn't install libffi from anywhere, it seemed to be there in his Mac by itself, so I inferred that to mean OS X itself put it there (it is a common package used by many things like python etc., so I figured they automatically include it in OS X). The change I made allowed him to run just fine. So I literally have a sample space of 1. I'd like a Mac expert to take up the reins here so that we'll have a larger sample space.

smithzv@belial:[0]:~/$ locate ffi/ffi.h

This is from MacPorts (they changed there name a while back).

Yup, I knew that but forgot it. This is proof of my lack of Mac expertise :-).

smithzv@belial:[0]:~/$ ls /opt/local/include/ffi.h /opt/local/include/ffi.h

...

So I'm going to rely on your Mac expertise here (because I have none)

Neither do I really, just GNU/Linux experience that I am trying to use on OS X.

Then I think until a Mac expert steps up and enlightens us with the Mac Way to solve this, I think I'll leave my code as it is.

...

but can you answer the questions I asked of Jason?  (modified suitably for OS X).  What was the path you gave it?  Why isn't ffi.h in the Apple-defined place?  etc.  You say in your other message "...I have for a long time had to do this for any system that uses cffi-grovel, since I often have libraries in only somewhat standard places under OS X."

...

If they are in different places because of the semi-standard install (e.g. Darwin ports), arguably we should have that in GSLL.

I am leaving all of my package managed files in the default directories that the package managers use.  For MacPorts that is /opt/local, and for Fink that is /sw.  I would say that these are absolutely standard places for people who use MacPorts and Fink.  I will say that if you want to build software outside of these package managers, basically no one looks there by default.  If you want to support builds for people using MacPorts or Fink, you could have the user push an appropriate symbol onto *FEATURES* and use something like...

(cffi-grovel:grovel-file .... #+(or gsll:macports gsll:darwinports gsll:fink) :cc-flags #+(or macports darwinports)"-I/opt/local/include" #+fink"-I/sw/include")

I'm unclear on who/what put gsll:macports onto *features*. That's not anything I do, nor could I. Therefore I couldn't put it into my source code.

For FSBV, unfortunately, it seems that sometimes ffi is in a path like ffi/ffi.h, which means that a simple include flag will not work, instead you may have to do something like

#+(and gsll:darwin (not (or gsll:macports gsll:darwinports))) (include "ffi/ffi.h") #+(or (not darwin) (and gsll:darwin (or gsll:macports gsll:darwinports))) (include "ffi.h")

Not sure about fink here, since I use Macports for ffi.  Sorry for typos, I am typing this straight into the email.  Macports and fink typically use Linux like locations (i.e. they are not going to put a header in an extra subdirectory since it would break many packages).

...

If on the other hand you have a unique organization, you're going to have to make your own modifications to each system.  I don't know of a way to supply a list of possibilities to search in cffi-grovel, but even if that's possible, I'd only make use of it for semi-standard locations.

Right.  So if I am building a C library like GSL, I typically define a build environment.  This includes a location of where header files are found and where libraries are found.  These locations are not carried in the source of the program because, quite frankly, it isn't the responsibility of the developer to know what loopy places a user might put his/her files.  But since every build system I know of that handles C like builds (GNU autotools, CMake, SCons, whatever that thing is you use on OS X) allows you to specify the location of headers and libraries, I am allowed to build packages without keeping my own set of patches to someone else's source tree.  Quite often these locations are by default read from environment variables like CFLAGS and LDFLAGS.

It makes sense to me that this shouldn't happen at the GSLL level.  I think I am more sure of that now.  CFFI deals with libraries, like a linker, and it offers a special variable CFFI:*FOREIGN-LIBRARY-DIRECTORIES* that acts a lot like the environment variable LDFLAGS.  Since CFFI-grovel deals with (primarily) header files, should offer such a analog for the environment variable CFLAGS.  There is a variable CFFI-GROVEL:*CC-FLAGS* but any value it is bound to is thrown away prior to grovelling (it also can only specify only one token).  I could set these in my user init file and be done with it.

Doesn't this sound like a better solution for people who install libraries in their home space, or have a package manager that isn't integrated with the OS like me?  You move that responsibility off of your shoulders and onto the people who should know what is happening in there system, the users.

If this sounds good, I will bring it up with Luis, Zach

There are two separate issues here, somewhat related: 1) Can/should CFFI-grovel search a list in much the same way that libraries are searched? 2) What location(s) might the Mac install (official or semi-standard) the header files?

As far as 1 goes, I think it would be a good idea and I think you should bring it up on the CFFI mailing list. As far as 2 goes, we need a Mac expert. In fact, the merger of the two issues might be not just that a list can be provided but that if running on a Mac, then *all* the standard and semi-standard locations are searched without explicit reference to the paths. And of course this would be done with all OSes. I think that this is the case with libraries; there is some statement to the effect that system libraries are searched in standard places, so no special system knowledge is required. This could be expanded to headers too.

Since this must be a larger issue than FSBV/GSLL, I think it really should be brought up with the CFFI list; there is more likely to be a Mac expert who can step up and provide the search list in general.

Liam