[This is Pauls original document, *not* mine - cracauer] [It's quite out of date now, but may contain hints that I forgot to copy to README] How to rebuild CMUCL and/or add applications without losing your mind in the process. For best results, the directory tree used should have a certain format. I recommend the following: Pick a root node. Unpack CMU source tarball so the files are in directory 17f/ relative to your root. You get: 17f/assembly.. 17f/code... 17f/compiler.. etc Consider 17f read-only. Don't put anything new here. Unpack my x86 kit so they are in a sibling relationship to 17f. p86/assembly p86/code etc Make a directory for the compiler to write fasl files to. Maybe x86/assembly x86/code x86/clx x86/hemlock etc I use build/x86/* as I also have a AXP based cross compiler which puts .x86f files in build/ax86/* and native compiled files in build/axp/*. You need to have the complete tree structure matching the 17f structure including subdirs. Next, I have a directory just for hacking in that is outside of those. Make a file, say, setenv.lisp. Mine looks like this. ;;;;;;;;;;;;;;;;;;; (in-package "USER") (pushnew :cgc *features*) (pushnew :cmu17 *features*) (pushnew :small *features*) (pushnew :x86-lra *features*) ;<--- IMPORTANT else debugger won't work (setf (ext:search-list "target:") '( ;; This is what I use for my cross-compiler setup ;; and may be the default in the distribution. "/usr/local/lisp/cmucl/build/x86/" ; object dir ;; You might want to not go so deep. From the ;; suggestion above.. ;; "/usr/local/lisp/cmucl/x86/" "/usr/local/lisp/cmucl/mods/" ; work in progress "/usr/local/lisp/cmucl/p86/" ; x86 port "/usr/local/lisp/cmucl/17f/" ; source dir )) ;;; Tailor this for what you want. This is the basics. ;;; The worldload process will use these features or lack thereof. ;;(pushnew :no-compiler *features*) ;;(pushnew :no-pcl *features*) (pushnew :no-clx *features*) (pushnew :no-clm *features*) (pushnew :no-hemlock *features*) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; The key feature is the (search-list ...) facility and the target: specification. When a file is compiled, (compile-file "target:code/x") the directory paths are searched in order specified looking for x.lisp and no matter where it is found, the compiler output goes to the *first* directory in the list. This makes it possible to maintain a read-only source kit, and make changes in a working area that shadow original stuff without mucking up the original. To view the current definition, eval (search-list "target:"). BUILDING the C STARTUP CODE In order to do any real system building you will need to have critical files that are best gotten by building the C language support stuff from scratch. This is a bit tricky because the C codes include a critical file called 'internals.h' which is generated by lisp, but, you need a copy of file 'lisp.nm' which is generated by compiling/linking C code. To bootstrap this process, Cd to target:lisp (well you can't really do that in BSD). Make a symlink to the GNUmakefile and Config files found in p86/lisp. On my box, "ls -l" prints out something like this Config -> ../../../p86/lisp/Config GNUmakefile -> ../../../p86/lisp/GNUmakefile Now make the initial symbol table for the genesis process. You only have to do this once. echo 'Map file for lisp version 1' > lisp.nm nm `which lisp` | grep -v " F " >> lisp.nm You are now prepared to compile the C startup code, but you first have to make a critical file using lisp, so.. bash$ lisp * (load "setenv") ; site-specific search-list definitions * (load "target:compiler/generic/new-genesis") * (setf lisp::*genesis-core-name* "target:lisp/junk.core") * (setf lisp::*genesis-c-header-name* "target:lisp/internals.h") ; output * (setf lisp::*genesis-symbol-table* "target:lisp/lisp.nm") ; input * (lisp::genesis nil) This should get you a new internals.h. Ok, now build the C codes. bash$ touch Depends bash$ gmake depend bash$ gmake all Ok, now you have the foundation stuff in place. You don't have to come here again unless you want to hack the C code. BUILDING LISP Ok, so you have all that. Run lisp, * (load "setenv") * (defvar *interactive* nil) ; Send noise to log file * (compile-file "target:tools/setup" :load t) ; Needed by most cmu tools * #-pcl(load "target:tools/pclcom") ; Rebuild pcl. See note. * (load "target:tools/clxcom") ; rebuild clx * (load "target:tools/hemcom") ; rebuild hemlock and you have done it! Note: pcl is pre-loaded in the distribution kit, and cannot compile on top of itself. Normally I run the above procedure after first building a world consisting of just lisp + compiler. If you want to regenerate the binary kit so you can make a saved image from scratch. Start a clean lisp, * (load "setenv") * (load "target:tools/setup") * (load "target:tools/worldcom") ; Builds most of lisp * (load "target:tools/comcom") ; Build Python and backend * (load "target:tools/worldbuild") ; Make a new kernel.core Now, assuming all went well, you can build a new world. However you have just changed the 'lisp' executable and the new lisp kernel is tied to that version. Each time you rebuild the C code you will increment a version number that must match what genesis used. I usually keep a symlink in my hack directory that points to the current new lisp and kernel. Doing it the hard way.. bash$ ../build/x86/lisp/lisp -core ../build/x86/lisp/kernel.core * (in-package :user) * (load "setenv") ; site specific path defs * (load "target:tools/worldload") and you are done! Now just install the new 'lisp' and new lisp.core in the cmucl/bin cmucl/lib directories and your home. Wasn't that fun? There is a script in library: that is supposed to assist in building a tailored saved-image with just the systems you want. I have never tried using it.