[Gsll-devel] Build problems

[Liam Healy]

On Wed, Jun 24, 2009 at 2:52 PM, Zach<elzacho at gmail.com> wrote:
>
>
> On Tue, Jun 23, 2009 at 8:05 PM, Liam Healy <lhealy at 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 at 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 at 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