ViewVC logotype

Contents of /src/BUILDING

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.20 - (show annotations)
Tue Mar 25 15:16:36 2008 UTC (6 years, 1 month ago) by agoncharov
Branch: MAIN
CVS Tags: snapshot-2008-04
Changes since 1.19: +1 -0 lines
White space noise for CVS commit testing
1 -*- Mode: text -*-
3 Building CMU CL
4 ===============
6 This document is intended to give you a general overview of the build
7 process (i.e. what needs to be done, in what order, and what is it
8 generally called). It will also tell you how to set up a suitable
9 build environment, how the individual scripts fit into the general
10 scheme of things, and give you a couple of examples.
12 General Requirements
13 --------------------
15 In order to build CMU CL, you will need:
17 a) A working CMU CL binary. There is no way around this requirement!
19 This binary can either be for the platform you want to target, in
20 that case you can either recompile or cross-compile, or for another
21 supported platform, in that case you must cross-compile, obviously.
23 b) A supported C compiler for the C runtime code.
25 Most of the time, this means GNU gcc, though for some ports it
26 means the vendor-supplied C compiler. The compiler must be
27 available under the name specified by your ports Config file.
29 c) GNU make
31 This has to be available either as gmake or make in your PATH, or
32 the MAKE environment variable has to be set to point to the correct
33 binary.
35 d) The CMU CL source code
37 Here you can either use one of the release source tarballs, or
38 check out the source code directly from the public CMUCL CVS
39 repository.
41 If you want to build CMU CL's Motif interface/toolkit, you'll need a
42 working version of the Motif libraries, either true-blue OSF/Motif, or
43 OpenMotif, or Lesstif. The code was developed against 1.2 Motif,
44 though recompilation against 2.x Motif probably works as well.
46 Setting up a build environment
47 ------------------------------
49 1.) Create a base directory and change to it
51 mkdir cmucl ; cd cmucl
53 2.) Fetch the sources and put them into the base directory
55 tar xzf /tmp/cmucl-source.tar.gz
57 or, if you want to use the CVS sources directly:
59 export CVSROOT=:pserver:anonymous@common-lisp.net:/project/cmucl/cvsroot
60 cvs login (password is `anonymous')
61 cvs co src
63 Whatever you do, the sources must be in a directory named src
64 inside the base directory. Since the build tools keep all
65 generated files in separate target directories, the src directory
66 can be read-only (e.g. mounted read-only via NFS, etc.)
68 The build tools are all in the src/tools directory.
70 That's it, you are now ready to build CMU CL.
72 A quick guide for simple builds
73 -------------------------------
75 We recommend that you read all of this document, but in case you don't
76 want to do that and in case you know, somehow, that the version of
77 CMUCL you are building from will build the sources you have, here is a
78 quick guide.
80 a) Simple builds
82 Use this to build from a version of CMUCL that is very close to the
83 sources you are trying to build now:
85 src/tools/build.sh -C "" -o "<name-of-old-lisp> <options-to-lisp>"
87 This will build CMUCL 3 times, each time with the result of the
88 previous build. The last time, the additional libraries like CLX,
89 CLM, and Hemlock are built. The final result will be in the
90 directory build-4.
92 This script basically runs create-target.sh, build-world.sh,
93 load-world.sh three times. See below for descriptions of these
94 scripts.
96 b) Slightly more complicated builds
98 For slightly more complicated builds, you may need to use some
99 bootstrap files. See below for more information about these
100 bootstrap files.
102 For these, you can use this:
104 src/tools/build.sh -C "" -o "<old-lisp>" -B boot1.lisp -B boot2.lisp
106 The bootstrap files listed with the -B option (as many as needed)
107 are loaded in order, so be sure to get them right.
109 As in a) above, three builds are done, and the result is in the
110 directory build-4.
112 c) More complicated builds
114 If you have more complicated builds, this script probably will not
115 work, and definitely does not handle cross-compiles. In this case,
116 you will have to invoke the individual scripts by hand, as
117 described below.
119 How do you know which of the three options above apply? The easiest
120 way is to look in src/bootfiles/<version>/* for boot files. If the
121 file date of a boot file is later than the version of CMUCL you are
122 building from, then you need to use b) or c) above. You may need to
123 read the bootfiles for additional instructions, if any.
125 If there are no bootfiles, then you can use a) above.
127 The build.sh script supports other options, and src/tools/build.sh -?
128 will give a quick summary. Read src/tools/build.sh for more
129 information.
131 A general outline of the build process
132 --------------------------------------
134 Building CMU CL can happen in one of two ways: Normal recompilation,
135 and cross-compilation. We'll first look at normal recompilation:
137 The recompilation process basically consists of 4 phases/parts:
139 a) Compiling the lisp files that make up the standard kernel.
141 This happens in your current CMU CL process, using your current
142 CMU CL's normal file compiler. This phase currently consists of 3
143 sub-phases, namely those controlled by src/tools/worldcom.lisp,
144 which compiles all the runtime files, src/tools/comcom.lisp, which
145 compiles the compiler (including your chosen backend), and finally
146 src/tools/pclcom.lisp, which compiles PCL, CMU CL's CLOS
147 implementation. The whole phase is often called "world-compile",
148 or "compiling up a world", based on the name of the first
149 sub-phase.
151 b) Building a new kernel.core file out of the so created files
153 This process, which is generally called genesis, and which is
154 controlled by src/tools/worldbuild.lisp, uses the newly compiled
155 files in order to build a new, basic core file, which is then used
156 by the last phase to create a fully functional normal core file.
157 It does this by "loading" the compiled files into an in-core
158 representation of a new core file, which is then dumped out to
159 disk, together with lots of fixups that need to happen once the new
160 core is started.
162 As part of this process, it also creates the file internals.h,
163 which contains information about the general memory layout of the
164 new core and its basic types, their type tags, and the location of
165 several important constants and other variables, that are needed by
166 the C runtime code to work with the given core.
168 So going through genesis is needed to create internals.h, which is
169 needed to compile the C runtime code (i.e. the "lisp" binary).
170 However there is a slight circularity here, since genesis needs as
171 one of its inputs the file target:lisp/lisp.nm, which contains the
172 (slightly pre-treated) output of running nm on the new lisp
173 binary. Genesis uses this information to fixup the addresses of C
174 runtime support functions for calls from Lisp code.
176 However the circularity isn't complete, since genesis can work with
177 an empty/bogus lisp.nm file. While the kernel.core it then
178 produces is unusable, it will create a usable internals.h file,
179 which can be used to recompile the C runtime code, producing a
180 usable lisp.nm file, which in turn can be used to restart genesis,
181 producing a working kernel.core file.
183 Genesis also checks whether the newly produced internals.h file
184 differs from a pre-existing internals.h file (this might be caused
185 by an empty internals.h file if you are rebuilding for the first
186 time, or by changes in the lisp sources that cause differences in
187 the memory layout of the kernel.core), and informs you of this, so
188 that you can recompile the C runtime code, and restart genesis.
190 If it doesn't inform you of this, you can skip directly to the last
191 phase d).
193 c) Recompiling the C runtime code, producing the "lisp" binary file
195 This step is only needed if you haven't yet got a suitable lisp
196 binary, or if the internals.h file has changed during genesis (of
197 which genesis informs you), or when you made changes to the C
198 sources that you want to take effect.
200 Recompiling the C runtime code is controlled by a GNU Makefile, and
201 your target's Config file. It depends on a correct internals.h
202 file as produced by genesis.
204 Note that whenever you recompile the runtime code, for whatever
205 reason, you must redo phase b). Note that if you make changes to
206 the C sources and recompile because of this, you can do that before
207 Phase b), so that you don't have to perform that phase twice.
209 d) Populating the kernel.core, and dumping a new lisp.core file.
211 In this phase, which is controlled by src/tools/worldload.lisp, and
212 hence often called world-load, the kernel.core file is started up
213 using the (possibly new) lisp binary, the remaining files which
214 were compiled in phase a) are loaded into it, and a new lisp.core
215 file is dumped out.
217 We're not quite done yet. This produces just a basic lisp.core.
218 To complete the build so that you something similar to what the
219 releases of CMUCL do, there are a few more steps:
221 e) Build the utilities like Gray streams, simple streams, CLX, CLM,
222 and Hemlock. Use the src/tools/build-utils.sh script for this, as
223 described below
225 f) Create tarfiles using the src/tools/make-dist.sh script, as
226 explained below.
228 With these tarfiles, you can install them anywhere. The contents of
229 the tarfiles will be the same as the snapshots and releases of CMUCL.
231 When cross-compiling, there is additional phase at the beginning, and
232 some of the phases happen with different hosts/platforms. The initial
233 phase is setting up and compiling the cross-compilation backend, using
234 your current compiler. The new backend is then loaded, and all
235 compilation in phase a) happens using this compiler backend. The
236 creation of the kernel.core file in phase b) happens as usual, while
237 phase c) of course happens on the target platform (if that differs
238 from the host platform), as does the final phase d). Another major
239 difference is that you can't compile PCL using the cross-compiler, so
240 one usually does a normal rebuild using the cross-compiled core on the
241 target platform to get a full CMU CL core.
243 So, now you know all about CMU CL compilation, how does that map onto
244 the scripts included with this little text?
246 Overview of the included build scripts
247 --------------------------------------
249 * src/tools/create-target.sh target-directory [lisp-variant [motif-variant]]
251 This script creates a new target directory, which is a shadow of the
252 source directory, that will contain all the files that are created by
253 the build process. Thus, each target's files are completely separate
254 from the src directory, which could, in fact, be read-only. Hence you
255 can simultaneously build CMUCL for different targets from the same
256 source directory.
258 The first argument is the name of the target directory to create. The
259 remaining arguments are optional. If they are not given, the script
260 tries to determine the lisp variant and motif variant from the system
261 the script is running on.
263 The lisp-variant (i.e. the suffix of the src/lisp/Config.* to use as
264 the target's Config file), and optionally the motif-variant (again the
265 suffix of the src/motif/server/Config.* file to use as the Config file
266 for the target's CMUCL/Motif server code). If the lisp-variant is
267 given but the motif-variant is not, the motif-variant is determined
268 from the lisp-variant.
270 The script will generate the target directory tree, link the relevant
271 Config files, and generate place-holder files for various files, in
272 order to ensure proper operation of the other build-scripts. It also
273 creates a sample setenv.lisp file in the target directory, which is
274 used by the build and load processes to set up the correct list of
275 *features* for your target lisp core.
277 IMPORTANT: You will normally NOT have to modify the sample setenv.lisp
278 file, if you are building from a binary that has the desired features.
279 In fact, the sample has all code commented out, If you want to add or
280 remove features, you need to include code that puts at least a minimal
281 set of features onto the list (use PUSHNEW and/or REMOVE). You can
282 use the current set of *features* of your lisp as a first guide. The
283 sample setenv.lisp includes a set of features that should work for the
284 intended configuration. Note also that some adding or removing some
285 features may require a cross-compile instead of a normal compile.
287 * src/tools/clean-target.sh [-l] target-directory [more dirs]
289 Cleans the given target directory, so that all created files will be
290 removed. This is useful to force recompilation. If the -l flag is
291 given, then the C runtime is also removed, including all the lisp
292 executable, any lisp cores, all object files, lisp.nm, internals.h,
293 and the config file.
295 * src/tools/build-world.sh target-directory [build-binary] [build-flags...]
297 Starts a complete world build for the given target, using the lisp
298 binary/core specified as a build host. The recompilation step will
299 only recompile changed files, or files for which the fasl files are
300 missing. It will also not recompile the C runtime code (the lisp
301 binary). If a (re)compilation of that code is needed, the genesis
302 step of the world build will inform you of that fact. In that case,
303 you'll have to use the rebuild-lisp.sh script, and then restart the
304 world build process with build-world.sh
306 * src/tools/rebuild-lisp.sh target-directory
308 This script will force a complete recompilation of the C runtime code
309 of CMU CL (aka the lisp executable). Doing this will necessitate
310 building a new kernel.core file, using build-world.sh.
312 * src/tools/load-world.sh target-directory version
314 This will finish the CMU CL rebuilding process, by loading the
315 remaining compiled files generated in the world build process into the
316 kernel.core file, that also resulted from that process, creating the
317 final lisp.core file.
319 You have to pass the version string as a second argument. The dumped
320 core will anounce itself using that string. Please don't use a string
321 consisting of an official release name only, (e.g. "18d"), since those
322 are reserved for official release builds. Including the build-date in
323 ISO8601 format is often a good idea, e.g. "18d+ 2002-05-06" for a
324 binary that is based on sources current on the 6th May, 2002, which is
325 post the 18d release.
327 * src/tools/build-utils.sh target-directory
329 This script will build auxiliary libraries packaged with CMU CL,
330 including CLX, CMUCL/Motif, the Motif debugger, inspector, and control
331 panel, and the Hemlock editor. It will use the lisp executable and
332 core of the given target.
334 * src/tools/make-dist.sh [-bg] [-G group] [-O owner] target-directory version arch os
336 This script creates both main and extra distribution tarballs from the
337 given target directory, using the make-main-dist.sh and
338 make-extra-dist.sh scripts. The result will be two tar files. One
339 contains the main distribution including the runtime and lisp.core
340 with PCL (CLOS); the second contains the extra libraries such as
341 Gray-streams, simple-streams, CLX, CLM, and Hemlock.
343 Some options that are available:
345 -b Use bzip2 compression
346 -g Use gzip compression
347 -G group Group to use
348 -O owner Owner to use
350 If you specify both -b and -g, you will get two sets of tarfiles. The
351 -G and -O options will attempt to set the owner and group of the files
352 when building the tarfiles. This way, when you extract the tarfiles,
353 the owner and group will be set as specified. You may need to be root
354 to do this because many Unix systems don't normally let you change the
355 owner and group of a file.
357 The remaining arguments used to create the name of the tarfiles. The
358 names will have the form:
360 cmucl-<version>-<arch>-<os>.tar.bz2
361 cmucl-<version>-<arch>-<os>.extras.tar.bz2
363 Of course, the "bz2" will be "gz" if you specified gzip compression
364 instead of bzip.
366 * /src/tools/make-main-dist.sh target-directory version arch os
368 This is script is not normally invoked by the user; make-dist will do
369 it appropriately.
371 This script creates a main distribution tarball (both in gzipped and
372 bzipped variants) from the given target directory. This will include
373 all the stuff that is normally included in official release tarballs
374 such as lisp.core and the PCL libraries, including Gray streams and
375 simple streams.
377 This is intended to be run from make-dist.sh.
379 * src/tools/make-extra-dist.sh target-directory version arch os
381 This is script is not normally invoked by the user; make-dist will do
382 it appropriately.
384 This script creates an extra distribution tarball (both in gzipped and
385 bzipped variants) from the given target directory. This will include
386 all the stuff that is normally included in official extra release
387 tarballs, i.e. the auxiliary libraries such as CLX, CLM, and Hemlock.
389 This is intended to be run from make-dist.sh.
392 * cross-build-world.sh target-directory cross-directory cross-script
393 [build-binary] [build-flags...]
395 This is a script that can be used instead of build-world.sh for
396 cross-compiling CMUCL. In addition to the arguments of build-world.sh
397 it takes two further required arguments: The name of a directory that
398 will contain the cross-compiler backend (the directory is created if
399 it doesn't exist, and must not be the same as the target-directory),
400 and the name of a Lisp cross-compilation script, which is responsible
401 for setting up, compiling, and loading the cross-compiler backend.
402 The latter argument is needed because each host/target combination of
403 platform's needs slightly different code to produce a working
404 cross-compiler.
406 We include a number of working examples of cross-compiler scripts in
407 the cross-scripts directory. You'll have to edit the features section
408 of the given scripts, to specify the features that should be removed
409 from the current set of features in the host lisp, and those that
410 should be added, so that the backend features are correct for the
411 intended target.
413 You can look at Eric Marsden's collection of build scripts for the
414 basis of more cross-compiler scripts.
416 Step-by-Step Example of recompiling CMUCL for OpenBSD
417 -----------------------------------------------------
419 Set up everything as described in the setup section above. Then
420 execute:
422 # Create a new target directory structure/config for OpenBSD:
423 src/tools/create-target.sh openbsd OpenBSD_gencgc OpenBSD
425 # edit openbsd/setenv.lisp to contain what we want:
426 cat <<EOF > openbsd/setenv.lisp
427 ;;; Put code to massage *features* list here...
429 (in-package :user)
431 (pushnew :openbsd *features*)
432 (pushnew :bsd *features*)
433 (pushnew :i486 *features*)
434 (pushnew :mp *features*)
435 (pushnew :hash-new *features*)
436 (pushnew :random-mt19937 *features*)
437 (pushnew :conservative-float-type *features*)
438 (pushnew :gencgc *features*)
440 ;;; Version tags
442 (pushnew :cmu18d *features*)
443 (pushnew :cmu18 *features*)
444 (setf *features* (remove :cmu17 *features*))
445 (setf *features* (remove :cmu18c *features*))
446 EOF
448 # Recompile the lisp world, and dump a new kernel.core:
449 src/tools/build-world.sh openbsd lisp # Or whatever you need to invoke your
450 # current lisp binary+core
452 # If build-world tells you (as it will the first time) that:
453 # "The C header file has changed. Be sure to re-compile the startup
454 # code."
455 # You 'll need to start rebuild-lisp.sh to do that, and then reinvoke
456 # build-world.sh:
458 # Recompile lisp binary itself:
459 src/tools/rebuild-lisp.sh openbsd
461 # Restart build-world.sh now:
462 src/tools/build-world.sh openbsd lisp
464 # Now we populate the kernel.core with further compiled files,
465 # and dump the final lisp.core file:
467 src/tools/load-world.sh openbsd "18d+ 2002-05-06"
469 # The second argument above is the version number that the built
470 # core will announce. Please always put the build-date and some
471 # other information in there, to make it possible to differentiate
472 # those builds from official builds, which only contain the release.
474 Now you should have a new lisp.core, which you can start with
476 ./openbsd/lisp/lisp -core ./openbsd/lisp/lisp.core -noinit -nositeinit
478 Compiling sources that contain disruptive changes
479 -------------------------------------------------
481 The above instructions should always work as-is for recompiling CMU CL
482 using matching binaries and source files. They also work quite often
483 when recompiling newer sources. However, every so often, some change
484 to the CMU CL sources necessitates some form of bootstrapping, so that
485 binaries built from earlier sources can compile the sources containing
486 that change. There are two forms of boostrapping that can be
487 required:
489 a) Bootfiles
491 The maintainers try to make bootfiles available, that allow going
492 from an old release to the next release. These are located in the
493 src/bootfiles/<old-release>/ directory of the CMU CL sources.
495 I.e. if you have binaries that match release 18d, then you'll need
496 to use all the bootfiles in src/bootfiles/18d/ in order to go to
497 the next release (or current sources, if no release has been made
498 yet). If you already used some of the bootstrap files to compile
499 your current lisp, you obviously don't need to use those to get to
500 later versions.
502 You can use the bootfiles by concatenating them into a file called
503 bootstrap.lisp in the target directory (i.e. target:bootstrap.lisp)
504 in the order they are numbered. Be sure to remove the bootstrap
505 file once it is no longer needed.
507 Alternatively, the bootstrap file can just "load" the individual
508 bootfiles as needed.
510 b) Cross-compiling
512 Under some circumstances, bootstrap code will not be sufficient,
513 and a cross-compilation is needed. In that case you will have to
514 use cross-build-world.sh, instead of build-world.sh. Please read
515 the instructions of that script for details of the more complex
516 procedure.
518 << This isn't really true anymore, and we should place a more
519 elaborate description of the cross-compiling process here >>
521 When cross-compiling, there are two sorts of bootscripts that can be
522 used: Those that want to be executed prior to compiling and loading
523 the cross-compiler, which should be placed in the file called
524 target:cross-bootstrap.lisp, and those that should happen after the
525 cross-compiler has been compiled and loaded, just prior to compiling
526 the target, which should be placed in target:bootstrap.lisp, just
527 like when doing a normal recompile.
529 Additionally, sometimes customized cross-compiler setup scripts
530 (to be used in place of e.g. cross-x86-x86.lisp) are required,
531 which are also placed in one of the bootfiles/*/* files. In those
532 cases follow the instructions provided in that file, possibly merging
533 the changed contents thereof with your normal cross-script.
535 Step-by-Step Example of Cross-Compiling
536 ---------------------------------------
538 This gives a step-by-step example of cross-compiling a sparc-v8 build
539 using a sparc-v9 build. (For some unknown reason, you can't just
540 remove the :sparc-v9 feature and add :sparc-v8.)
542 So, first get a recent sparc-v9 build. It's best to get a version
543 that is up-to-date with the sources. Otherwise, you may also need to
544 add a bootstrap file to get any bootfiles to make your lisp
545 up-to-date with the current sources.
547 1. Select a directory for the cross-compiler and compiled target:
549 Create a cross-compiler directory to hold the cross-compiler
550 and a target directory to hold the result:
552 src/tools/create-target.sh xcross
553 src/tools/create-target.sh xtarget
555 2. Adjust cross-compilation script
557 Copy the src/tools/cross-scripts/cross-sparc-sparc.lisp to
558 xtarget/cross.lisp. Edit it appropriately. In this case, it
559 should look something like:
561 (c::new-backend "SPARC"
562 ;; Features to add here
563 '(:sparc :sparc-v8
564 :complex-fp-vops
565 :linkage-table
566 :gencgc
567 :stack-checking
568 :relative-package-names
569 :conservative-float-type
570 :hash-new :random-mt19937
571 :cmu :cmu19 :cmu19a
572 )
573 ;; Features to remove from current *features* here
574 '(:sparc-v9 :sparc-v7 :x86 :x86-bootstrap :alpha :osf1 :mips
575 :propagate-fun-type :propagate-float-type :constrain-float-type
576 :openbsd :freebsd :glibc2 :linux :pentium
577 :long-float :new-random :small))
579 (setf *features* (remove :sparc-v9 *features*))
580 (pushnew :sparc-v8 *features*)
582 It's important to add frob *features* here as well as in the
583 new-backend. If you don't adjust *features*, they won't be
584 set appropriately in the result.
586 3. Build the cross compiler and target
587 Now compile the result:
589 src/tools/cross-build-world.sh xtarget xcross xtarget/cross.lisp [v9 binary]
591 4. Rebuild the lisp files:
593 When this finishes, you need to compile the C code:
595 src/tools/rebuild-lisp.sh xtarget
597 At this point, you may want to run cross-build-world.sh again
598 to generate a new kernel.core. It shouldn't build anything;
599 just loads everything and creates a kernel.core.
601 5. Build the world:
603 With the new kernel.core, we need to create a lisp.core:
605 src/tools/load-world.sh xtarget "new lisp"
607 Test the result with
609 xtarget/lisp/lisp -noinit
611 However, this lisp will be missing some functionality like PCL. You
612 probably now want to use the compiler to rebuild everything once
613 again. Just follow the directions for a normal build, and use
614 xtarget/lisp/lisp as your compiler. Be sure to use create-target.sh
615 to create a new directory where the result can go.
617 Cross-Platform Cross-Compile
618 ----------------------------
620 A cross-platform cross-compile is very similar to a normal
621 cross-compile, and the basic steps are the same. For the sake of
622 concreteness, assume we are on ppc/darwin and want to cross-compile
623 to x86/linux.
625 To simplify things, we assume that both platforms have access to the
626 same file system, via NFS or something else.
628 1. As above, we need to create directories for the cross-compiler and
629 compiled target. We assume we are on ppc/darwin. So, when running
630 create-target.sh we need to specify the target:
632 src/tools/create-target.sh x86-cross x86
633 src/tools/create-target.sh x86-target x86
635 2. Adjust the cross-compilation script. An example for ppc/darwin to
636 x86/linux is in src/tools/cross-scripts/cross-ppc-x86.lisp.
638 3. Build the cross compiler and target, as above, using the specified
639 cross-compile script:
641 src/tools/cross-build-world.sh x86-target x86-cross cross.lisp [ppc binary]
643 where cross.lisp is the cross-compile script from 2) above.
645 4. Everything has now been compiled for the x86/linux target. We need
646 to compile the C code for x86 and create a lisp.core from the
647 kernel.core. This is where it's useful to have both platforms be
648 able to access the same file system. If not, you will need to copy
649 all of the generated files from ppc/darwin to x86/linux. Basically
650 everything in xtarget needs to be copied.
652 Note carefully that you may have to edit lisp/internals.h and/or
653 lisp/internals.inc to have the correct features. This is a known
654 bug in the generation of these files during cross-compilation.
656 Compile the lisp code:
658 src/tools/rebuild-lisp.sh x86-target
660 5. Now run load-world.sh to create the desired lisp.core from lisp and
661 kernel.core. As above, PCL has not been compiled, so select
662 restart 3 (return nil from pclload) to create lisp.core
664 src/tools/load-world.sh x86-target "new x86"
666 At this point, you will have a shiny new lisp on the new platform.
667 Since it's missing PCL, you will need to do at least one normal build
668 to get PCL included. This is also a good check to see if everything
669 was compiled properly. A full set of builds via build.sh might be
670 good at this point too.

  ViewVC Help
Powered by ViewVC 1.1.5