[Openmcl-devel] Building from CVS

[Gary Byers]

On Wed, 6 Apr 2005, David Steuber wrote:

>
> I've fiddled with my build script a bit but it will still fail for
> bootstrapping situations.  In spite of that, I do like to have it for a
> lazy way to rebuild OpenMCL after doing a cvs up.  Perhaps someone on
> this list can suggest ways to make the script more robust for when a
> bootstrapping situation occurs?
>
> Thanks!
>
>

The script (compile the kernel, do (COMPILE-CCL T), do (XLOAD-LEVEL-0
:FORCE), load the new "ppc-boot[.image]", save the new image) works
fine when the image you have (with all of the constants and macros
and compiler behavior and ...) matches the sources that you're compiling
(e.g. when there are "no bootstrapping issues.")

When there are bootstrapping issues, what you need to do depends on
what those issues are.

Suppose that the macro FOO expands into a call to the function
CCL::%FOO (defined somewhere in "ccl:level-0;"), that there are many
uses of FOO (and therefore many calls to CCL::%FOO) in the system,
and that whatever CCL::%FOO does, it's pretty critical to the entire
system (e.g., the reader won't work unless #'%FOO does whatever it
does.)

Suppose that it's also discovered that there's a bug in CCL::%FOO
(every call to it leaks a few KB of memory or something like that),
and that it'd really be better if the macro FOO expanded into a
call to the much better, kinder, gentler function CCL::%BAR, which
takes the same args as CCL::%FOO but takes them in a different order.
The source code in CVS changes: the function %FOO is deleted, the
function %BAR is added, and the macro FOO changes.

To bootstrap this change (from an "old image", that still contains
the old macro definition and the old function) might require a series
of steps like:

1) find the definition of the new function in an editor and mouse
on it (C-M-X or something similar), so that CCL::%BAR is defined
as well as CCL::%FOO.

2) find the definition of the macro FOO and mouse on it (or compile
and load the file it contains.)

3) recompile everything. As things are compiled and loaded during
COMPILE-CCL, some functions will contains calls to CCL::%BAR and
some will contain calls to CCL::%FOO.  Since both functions are
defined in the current environment, that's OK in this case.

4) keep this "hybrid" image running; try loading a new ppc-boot
image in another shell.  If it fails, you missed something.  Keep
repeating the last few steps until you're sure that you got everything.
Eventually, get it right.

That's a contrived example, but it's fairly typical.  Sometimes, the
nature of a change is such that code running in the compilation
environment (the place where the bootstrapping is to take place)
has to incoprorate the change as soon as possible; other times, it's
critical that code running in the compilation environment -not-
incorporate a change (but that the fasls it produces do.)

It's hard to generalize this, and pretty hard to imagine how it
could be generalized.  I've done this sort of thing thousands of
times, and I still completely screw things up on a fairly regular
basis (and sometimes don't find out that I did so until some
problem manifests itself a few days later.)

There isn't any sort of secret (general) recipe; there are a lot
of ad-hoc, one-time-only approaches to specific issues.  If anyone's
ever interested in knowing how particular changes are bootstrapped,
I'll try to explain how I did something. I think that it's probably
of limited interest most of the time, and I try to provide images
in the testing directory as soon as the dust appears to have settled.