[Openmcl-devel] cllDirectory from OS X defaults overrides current setting when building the Cocoa IDE

[Martin Kühl]

Hi List,

I've recently run into a problem where I couldn't build the Cocoa IDE
from my checkout in ~/src/lisp/ccl, but could when I moved the same
checkout to ~/Projects/ccl. The error message was:

| ;Loading #P"ccl:cocoa-ide;fasls;start.dx64fsl.newest"...
| > Error: Module EASYGUI was not provided by any function on
*MODULE-PROVIDER-FUNCTIONS*.
| > While executing: REQUIRE, in process listener(1).

I found the problem by now; you might consider it a user error, or a
bug, or both, I'll just go on and document it here.

The problem could be narrowed down to this symptom:

| ? (ccl::find-module-pathnames "EASYGUI")
| NIL

but it only occurred after requiring "COCOA-APPLICATION", while it
still worked after requiring "COCOA".

The real problem was that I had built the IDE before, in
~/Projects/ccl, and had set that as cclDirectory in the IDEs
preferences (so I could load asdf-install). Starting the IDE (with the
name set in in cocoa-application.lisp) loads that preference file and
overrides the running lisps CCL_DEFAULT_DIRECTORY, rendering it unable
to locate extensions. Just requiring "COCOA" uses a different bundle
identifier for the app, so it doesn't use the same preference file.

So, the single line fix was running this in my shell:
$ defaults delete com.clozure.Clozure\ CL cclDirectory

So, a user error, obviously. Still, I found the error rather hard to
diagnose, and certainly didn't expect the app preferences modifying
the process of building the app. Maybe the build process could be
modified so a defined cclDirectory isn't overridden by the defaults
setting? Or maybe the IDE could do simple sanity checks on that
setting?

Anyway, this should help other people that run into the same problem.

Cheers,
Martin