[Openmcl-devel] Finding the CDB interface files
ch-openmcl at bobobeach.com
Mon Jan 24 00:22:41 UTC 2005
I've done a bit of this with the vimage framework with reasonable luck.
I'll try and package this up in the next couple days, but
the general idea is:
and then (after appropriate package def, etc...)
(defun add-logical-pathname-translation (host log phy)
(let ((q (assoc log (logical-pathname-translations host) :test
(rplacd q (list phy))
(setf (logical-pathname-translations host)
(append (list (list log phy))
(defun local-directory (&rest path)
(make-pathname :directory (apply 'list :relative :up :up path))
(make-pathname :directory (pathname-directory *load-truename*)))))
And then to use:
I'll try and clean up, document etc... one of these days.
On Jan 23, 2005, at 3:51 PM, Gary Byers wrote:
> On Fri, 21 Jan 2005, David Steuber wrote:
>> I keep my openmcl in /Users/david/usr/src/ccl/. Openmcl has no
>> difficulty finding the interface files when started from SLIME or
>> running the openmcl script in Terminal. However, when I save an image
>> with save-application and use it in an application bundle, it can't
>> find the interface files (I use slime-connect to talk to the running
>> application). What form do I need to have evaluated to fix that
> The Darwin interfaces are presumed to be in the directory denoted by
> the logical pathname "ccl:darwin-headers;", so the question is sort
> of "how do logical pathname translations for the logical host CCL
> get set up?", or, if you prefer, "what physical directory does the
> CCL logical host use as the base for all relative logical pathnames?"
> The function CCL::CCL-DIRECTORY is called each time the lisp starts
> up to try to provide an answer to this question. (There are many
> potential answers, and it'd be nice to make this a little more
> flexible. perhaps by defining a method on the application class.)
> CCL::CCL-DIRECTORY tries to use (in order):
> 1) the value of the "CCL_DEFAULT_DIRECTORY" environment variable,
> which is ordinarily set by the "openmcl" shell script;
> 2) a Resources/ccl directory, relative to the pathname of the
> executable. (e.g., if the executable file resides in
> "MyApp.app/Contents/MacOS/dppccl", it will look for
> "MyApp.app/Contents/Resources/ccl/", which IIRC can be a
> symbolic link to the "real" CCL directory);
> 3) the current directory
>> A nearly related question: Building the FFI files does not work for
>> because I do not have GCC 2.95 on my system. Is there anyway for the
>> FFIGEN stuff to work with GCC 3.3?
> Helmut Eller got FFIGEN working with GCC 3.x several months ago. I
> haven't had time to make binaries available (or even to help other
> people who offered to do so.)
>> Going even further astray, has anyone got any C header file parsing
>> code in Lisp that can generate Lisp code for using the other FFI
>> functions like EXTERNAL-CALL? And can I manually declare foreign
>> that will work with RLET/PREF, etc?
> Defining foreign types is, AFAIK, documented.
> There should be a documented way of doing what #_ does (without
> relying on the interface database.) IIRC, the undocumented way got
> broken quite a while ago.
>> This is in aid of being able to use agl.h along with AGL.framework
>> without killing my fingers typing huge amounts of FFI code.
>> QuickTime.framework is in the future as well if I get that far.
> You really should be able to do this more easily.
> As an experiment, I just tried taking 10 minutes away from my other
> job on a Sunday afternoon. There are archives containing AGL and
> QT interfaces on the FTP server; so far, the earth hasn't started
> spinning off its axis.
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel