[Openmcl-devel] Application bundles and the interface database

[Gary Byers]

On Tue, 25 Oct 2005, Tord Kallqvist Romstad wrote:

> I am the author of a chess program developed with OpenMCL and Bosco:
>
> http://www.glaurungchess.com

That looks neat (I just looked at the screenshots.)

>
> The Cocoa GUI works fine on my iMac, but it has been brought to my
> attention that the application doesn't work at all on Macs without
> OpenMCL installed.  I have been able to confirm this by renaming my
> ccl directory.  The following information appears in console.log:
>
> ; Warning: Interface file #P"ccl:darwin-headers;cocoa;objc-methods.cdb" does not exist.
> ; While executing: CCL::CDB-OPEN
>> Error: value NIL is not of the expected type STRUCTURE  .
>> While executing: CCL::%PARSE-MESSAGE
>
> Is there any easy way to include the necessary parts of the interface
> database in the application bundle?

I have to confess to a certain amount (a large amount) of Bosco ignorance;
Bosco may provide a better way of doing this, and there are certainly
lots of different ways.

The demo IDE's application bundle's Info.plist file defines a string-valued
key named "CCLDefaultDirectory" with the value "../".  A function named
RESET-CCL-DIRECTORY is called at application startup and tries to obtain
the value of that key from the bundle's info-dictionary.  If it's able
to do so, it tries (probably not too robustly) to treat that string and
a string and a string denoting the bundle's path as pathnames, does
a MERGE-PATHNAMES on them, and tries to set the logical-pathname-translations
for the "CCL" logical host based on the result.

That "works" (for some value of "work") if the application bundle is
embedded in the "real" CCL directory; the merged pathname winds up
as something like:

#p"/path/to/ccl/OpenMCL.app/../".  Of course, it breaks as soon
as you move the application bundle elsewhere.

It'd probably make more sense to set the "CCLDefaultDirectory" key to
point to either an absolute filesystem location (somewhere like a
subdirectory of /Library/Frameworks/OpenMCL.framework/) or to some
relative location inside the bundle (like "Contents/ccl/" or 
"Contents/Resources/ccl" or just "Contents/Resources/").  If OpenMCL.app
was really usable, it might make some sense to distribute the ccl
directory inside of the bundle (instead of the other way around);
I think that Alex Crain basically did this in the Hemlock that he
released a few months ago, and it seemed to work well.

You presumably don't have to worry about distributing the whole
ccl hierarchy, but apparently you do need to access the interfaces
at runtime.  (I'm not sure whether your application needs to do that
or whether the bridge is doing it; if it's the bridge, I don't think
that it should need to.)  You basically just need the logical pathname
"ccl:darwin-headers;" to translate to some some physical pathname
- inside the bundle hierarchy, since that seems simplest - which is
easiest to do if you can arrange that (TRUENAME "ccl:") refers
to a directory that contains a "darwin-headers/" directory and
its subdirectories (at least cocoa/).

So, if you can use the CCLDefaultDirectory/RESET-CCL-DIRECTORY
mechanism, you could (for instance) install darwin-headers/cocoa/*.cdb
in YourApp.app/Contents/Resources/, set the "CCLDefaultDirectory"
key in the Info.plist file to "Contents/Resources/", and (knock wood)
that should enable the lisp to find the .cdb files.

(The next step, I guess, is to try to determine why it wants them
at runtime ...)

>
> -- 
> Tord Romstad
>
>