Version 1 (modified by gb, 11 years ago) (diff)


Tracking changes to the trunk (aka "the bleeding edge")

Most day-to-day development activity in CCL happens in "the trunk" (a designated part of the svn repository hierarchy.) Sometimes, the trunk version of Clozure CL may contain interesting new features. (Other times, it may contain new features that aren't very interesting ...) Often, the trunk version of CCL is perfectly usable for day-to-day work; sometimes, it doesn't even build or run reliably. Sometimes, we're able to anticipate when development activity is likely to create instability in the trunk (and try to advise readers of the 'openmcl-devel' mailing list of this); other times, instability comes as a complete surprise to all concerned.

If those warnings don't scare you off and you want to use and track changes to the trunk, the procedure for doing so is fairly simple. (If you haven't done so recently, you might want to read UpdatingFromSource, which describes how to track changes in the 'release' hierarchy; the procdure for using the trunk is very similar.)

Checking out a copy of the trunk contents from svn

Working copies of the trunk aren't distributed in tar archives, but (since all sources and binaries are maintained in svn) it's possible to obtain a complete "ccl" hierarchy for any supported platform by using the svn checkout commmand. ("svn checkout" can be abbreviated as "svn co", and the abbreviate form is used below.)

In the shell, "cd" to some directory that doesn't contain a subdirectory named "ccl" and do:

shell> svn co

where "PLATFORM" describes the machine architecture/OS that you're interested in. You can generally get a good idea of what PLATFORMs are supported by looking at in a web browser; the supported platforms may not match those available in the current release (support for new platforms may be added and existing ones may be consolidated.)

By default, that'll create a directory called "ccl" in the shell's current directory and create an svn working copy in that ccl directory. The name of that directory is taken from the last component of the URL; if you prefer, you can do something like:

shell> svn co ''other-dir''

which will create a working copy in other-dir. (other-dir will be created and shouldn't already exist.)

Once the checkout completes, you probably want to update shell scripts/emacs configurations to make it easier to invoke the trunk lisp.

In the trunk lisp, the primary version number in the "Welcome!" banner (and in LISP-IMPLEMENTATION-VERSION) may not match the current release and LISP-IMPLEMENTATION-VERSION will contain the string "-trunk".

Tracking trunk changes

The procedure for tracking changes in the trunk is exactly the same as the procedure for tracking changes in the 'release' hierarchy, as described in UpdatingFromSource. The 'conflicting binaries" case is more common in the trunk, and warnings and constant-redefinition CERRORs during REBUILD-CCL are generally more common.

If you find that REBUILD-CCL doesn't work (or doesn't create a working lisp), the best advice would probably be to wait for a few hours/a day or so, try "svn update" and "(REBUILD-CCL :FULL T)" again, and only report it as a bug if it just persistently fails to build. (Looking at the svn commit messages in the Trac timeline above might also give an indication of whether a build failure is expected or not.)