Version 8 (modified by bfulgham, 14 years ago) (diff)

Clozure is placed in the 'ccl' directory after this step.

Updating from CVS and rebuilding OpenMCL from source

This page describes how to update and rebuild OpenMCL from CVS, starting with the most recent "snapshot" tarball. ("Snapshot tarballs" are distributed periodically in ) Feel free to mentally substitute "Clozure CL" for "OpenMCL".

  1. In a shell, enter the "ccl" directory created when the tarball was extracted.
    shell> cd ccl
  1. If you've never done so before on the current account on the current machine, "login" to the CVS server
    shell>cvs login

The password is "cvs". You may see some ominous looking warnings about "~/.cvspass" not existing and having to be created; these are actually benign and expected (but phrased in a way that makes it sound like something bad is happening. It isn't; we want CVS to create a ~/.cvspass file, and store the trivially-encrypted password there.)

  1. Tell CVS to update the sources, creating new directories and removing empty ones as needed.
    shell> cvs update -d -P

The "d" above is lowercase, the "P" is uppercase, and case matters.

  1. Once CVS has finished creating local copies of files that have changed on the CVS server since the last time you did this (or since the tarballs were created), use the currently installed OpenMCL to compile the updated sources and build a new kernel and heap image:
shell> openmcl  # or "openmcl64", or m-x slime, or whatever you do to start OpenMCL
Welcome to whatever version this is!
? (ccl:rebuild-ccl :force t)

That'll recompile the lisp kernel and all lisp sources used to build a heap image and build that image. Once that completes (usually takes 1 minute +/- 30 seconds) there should be a new heap image and new lisp kernel. There may be compiler warnings during compilation, usually related to calls to functions that will be defined when the process finishes but which are not yet defined during compilation (or which take a different number of arguments at compile time than they will when the image is built, etc.) Once in a while, some constants get redefined and a continuable error is signaled; continue from the CERROR to use the new value.

After a while, this (simple and simple-minded) bootstrapping process will cease to work: the newer source code will diverge from the code used to build the lisp image enough that it'll have to be bootstrapped in a more complicated (and usually totally ad-hoc) way. When this happens, new tarballs are produced.

Tracking changes

A ChangeLog (basically, svn commit history that affects the trunk) file is maintained as part of the source hierarchy and regenerated automatically every hour or so; when it changes, it's also copied to the ftp testing directory on Glancing at this file every now and then enables you to see whether recent changes are of interest to you.

It's also possible to use the "Timeline" feature on this Trac site for that purpose; the Timeline also keeps track of svn commits to development branches, bug report activity, and changes to Wiki pages. Note that the Trac site makes the Timeline available via RSS; use the orange XML button at the bottom of the Timeline to subscribe.


1) OpenMCL development actually takes place using subversion (as the "Browse Source" and "Timeline" and other links on this Trac site indicate); the CVS repository is synchronized with the SVN trunk about once an hour (currently at around 20 minutes past the hour and usually takes a few minutes.) At some not-too-distant point, it'd probably make sense to switch to SVN completely and to stop having to worry about mirroring things in CVS; CVS is still a little more widely available than SVN (comes with XCode tools on OSX Tiger and earlier, but SVN isn't bundled prior to Leopard.)

2) Since sometime in September 2007, the version number (in the greeting message and in LISP-IMPLEMENTATION-VERSION) will try to incorporate the SVN revision.

3) These instructions assume that it's possible to connect to TCP port 2401 on; some firewalls may block traffic to that port. Subversion can generally use more standard protocols (http, ssh, https) that run on ports that firewalls don't block as often; it's possible (and not too difficult) to use SVN instead of CVS. See UpdateFromSubversion for instructions on how to do that.

The Cocoa IDE

Note that building the IDE on x86-64 Leopard requires that interface files describing Cocoa classes, methods, and data structures be installed in ccl/darwin-x86-headers64/cocoa/*.cdb . These files are not included in OpenMCL snapshots released prior to Leopard's release (in late October 2007); an archive containing just those .cdb files is availale at .

People interested in using the Cocoa IDE ("Clozure") can rebuild it by simply doing:


in a freshly-updated OpenMCL. That'll initialize the ObjC bridge, load the lisp sources that comprise the IDE, compile and load a few dozen Hemlock source files, start the GUI, and then save an executable heap image in ccl/Clozure\ The standalone IDE may need to know where the "ccl" directory is (in order to find interface definitions used by the bridge and FFI and in order for things like REQUIRE and Meta-. to find lisp files; this can be set via a pane in the preferences panel. (Some of the pre-build .dmg files announced on info-mcl and on openmcl-devel in October 2007 contained their interface files inside the application bundle; this simplified distribution a bit but that may not be the "final" approach to this issue.)

It's also possible to do:

? (require "COCOA")

which does everything that requiring COCOA-APPLICATION does except for the last (save-application) step. In this case, the original listener thread stays active (as does the SLIME REPL thread) and the original listener stays connected to the process's standard I/O streams. The tradeoffs include:

  • A few more things (hard to remember what) work in the standalone IDE than work in the hybrid environment.

(The Help menu item that may invoke Apple's Help Viewer only works in the standalone IDE; there may be other things.)

  • Diagnostic output generally gets written to the process's standard output/error streams, meaning that it's

visible in the hybrid environment but hidden a bit (written to a logging device) in the standalone .app. (Apple's "Console" application - in /Applications/Utilities? - can be used to view this output, which may be useful to include in bug reports.)