[Openmcl-devel] Specifying interface db file locations

[Gary Byers]

On Sun, 14 Dec 2003, Duncan Rose wrote:

>
> Is there a way to specify where the interface db files are located? It
> appears that lisp images saved somewhere other than the ccl directory
> can't find them.
>
> Thanks for any help,
>
> -Duncan
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>

USE-INTERFACE-DIR looks for the headers in subdirectories of the
directory denoted by the logical pathname "ccl:darwin-headers;"
(or "ccl:headers;" under Linux).

If you do:

? (logical-pathname-translations "CCL")

(you might want to pprint the result), you'll see that it's a list of
pairs, where the left-hand-side of each pair is a logical pathname
pattern and the right-hand-side is ... omething that the LHS should
translate into.  The right-hand-sides of the first dozen or so are
themselves logical pathnames; the last couple look something like:

 (#4P"ccl:ccl;*.*" #P"/usr/local/src/ccl/*.*")
 (#4P"ccl:**;*.*" #P"/usr/local/src/ccl/**/*.*"))

The RHS in both cases is a physical pathname; the leading directory
component - "/usr/local/src/ccl/", in my case - is (or should be)
the physical pathname of the "CCL" directory.

Note that - as these translations are written - it's assumed
that all logical pathnames that use the "CCL" logical host
denote physical pathnames relative to the "ccl" directory.
That's a reasonably assumption much of the time, but (a) it
needn't always be true and (b) it begs the question: where
exactly -is- the "ccl directory" ?

Whenever an OpenMCL image start up. it runs a function called
INIT-LOGICAL-DIRECTORIES (defined in "ccl:level-1;l1-boot.lisp").
It tries to modify the (similar) translations for the "HOME"
logical host to point to the current user's home directory, and
tries to make the translations for the "CCL" logical host point
to the "ccl directory".  It's pretty clear what "the user's
home directory" means: USER-HOMEDIR-PATHNAME should find that,
but it's a bit less clear what the function CCL-DIRECTORY
should return.

There are many reasonable choices, but what it in fact does
is to eithar
  a) use the value of the environment variable "CCL_DEFAULT_DIRECTORY"
     if that's set (it's usually set in the "openmcl" shell script,
     but can also be set by other means), or
  b) the current directory otherwise.

When a "bundled" application is launched under OSX (by double-clicking
on it or by using the "open" command), OSX helpfully sets that
application's current directory to /, so if the environment variable
isn't set in the "login window" process (the one that created and
manages the OSX desktop), the translations for the "CCL" logical
directory will be left pointing at #p"/".  As you mentioned in a
later message, it "works" to move/copy the darwin-headers directory
up to /, but isn't a very satisfactory solution.

The "cocoa-application" example tries another approach (and anyone
watching their console log while it's trying it will not that it
forgot to establish an autorelease pool while trying).  The function
RESET-CCL-DIRECTORY is defined near the top of
"ccl:examples;cocoa-application.lisp" and is called by the saved
application just before it starts the Cocoa event loop.  If the
CCL_DEFAULT_DIRECTORY is set, RESET-CCL-DIRECTORY does nothing.
Otherwise, if the bundle's "dictionary" (Info.plist) contains
a CCLDefaultDirectory key, the value of that key (and the
pathname to the bundle directory, e.g., "OpenMCL.app") are
merged together.  As it's distributed, OpenMCL.app's Info.plist
file contains the value "../" for this key, so if the application
bundle's physical pathname is "/path/to/ccl/OpenMCL.app/", merging
the pathname "../" with that yields "/path/to/ccl/".  Of course,
this falls down completely as you want to move the application
bundle out of the "ccl" directory: you'd have to edit the Info.plist
file every time that you did this.

The "right way" for a bundled application to find its auxiliary
files would probably be to either store those files inside the
bundle hierarchy or in some global location (a "framework").  Some
applications might have no need for or interest in the "ccl" directory,
but the demo IDE should probably start thinking about how to do this
the right way: people -should- be complaining about how feeble the
demo's editor is, not about this sort of thing ...