[Openmcl-devel] Re: Bosco build failure with new asdf

Gary Byers gb at clozure.com
Mon Dec 22 18:01:32 UTC 2003



On Mon, 22 Dec 2003, mikel evins wrote:

> This is a (very new) known incompatiility introduced in the newest
> openmcl.  I have attached a patched system definition that fixes the
> problem:
>
>

We should probably try to find a more general solution.

The primary reason for *DEFAULT-BUNDLE-PATH* to exist (and for
objc-runtime.lisp to try to ensure that it's set) is to keep people
from trying to do

? (require "COCOA")

without having downloaded and installed "ccl:OpenMCL;app;" (or at least
to keep them from sending bug reports when that fails.)

*DEFAULT-BUNDLE-EXECUTABLE-PATH* is a little weirder:  before opening
any of the Cocoa libraries, the value of this variable is used to
set an environment variable ("CFProcessPath") that persuades CFBundle
(and ultimately NSBundle) that it should act as if the current application
is really (by default) ccl:OpenMCL.app;Contents;MacOS;dppccl.  That
little bit of trickery is necessary when we're trying to turn a command-line
program (the regular dppccl) into a Cocoa application, but wouldn't be
necessary in Bosco's case (where the idea's more nearly to turn a
generic Cocoa application into a specialized one.)

If it were possible to ask for a quick show of hands when writing an
email message, I'd guess that I'd see that most people would say that
they find this all to be pretty confusing.  My guess is that Bosco's
development model will ultimately prove to be a better way of doing
things than schemes based on turning a command-line application into a
GUI application, and the need to play around with CFProcessPath should
probably disappear.

(For those who aren't confused, or don't want to be: the CFBundle
class uses the full pathname of the running application to find the
containing bundle directory.  There are several ways of finding "the
full pathname of the running application", but the value that the
CFProcessPath environment variable has during shared library
initialization seems to override the other ways.  CFBundle needs to
be set up properly in order for NSBundle to be set up properly, and
NSBundle needs to be set up properly in order for the Info.plist file,
.nib files, and other stuff to be found.)




More information about the Openmcl-devel mailing list