5.2 Different anchor mappings at different times

We can distinguish between four different anchor configurations which will be in effect at different times:

compilation:

At the time CMB.make runs, the anchor configuration is taken from file pathconfig.² This configuration maps anchors to their respective directories in the actual source tree. At the same time the policy which determines the names of binfiles and stablefiles is modified in such a way that all binfiles will be created in directory $u$.bin. arch- os and all stablefiles will be created in $u$.boot. arch- os. In particular, if $$a$ is the root anchor name controlling the path leading to an ML source file $$a$/$\cdots$/ file.sml, then the corresponding binfile will be created as $u$.bin. arch- os/$a$/$\cdots$/CM/ arch- os/ file.sml. Similarly, the stablefile for the library description $$a$/$\cdots$/ file.cm controlled by root anchor $$a$ gets written to $u$.boot. arch- os/$a$/$\cdots$/CM/ arch- os/ file.cm. (Notice how the anchor name $$a$ is being incorporated into the resulting pathnames.)

boot:

At bootstrap time (e.g., when the makeml script is invoked), CM scans the contents of $u$.boot. arch- os, and for each directory name $a$ it finds there it maps the anchor $$a$ to that directory. The result is that the location for library description $$a$/$\cdots$/ file.cm is considered to be $u$.bin. arch- os/$a$/$\cdots$/ file.cm, which means that--under the usual rules of CM-- the corresponding stablefile is going to be $u$.bin. arch- os/$a$/$\cdots$/CM/ arch- os/ file.cm. This is precisely where CMB.make created it. (Of course, the libary description file itself does not exist, but this is not a problem because the stablefile does.)

The resulting mapping for anchors is the one that is being saved to the newly generated heap image.

test:

After generating a new heap image $v$. arch- osname³, the makeml script will copy the hierarchy of directories under $u$.boot. arch- os to a new directory $v$.lib and generate a path configuration file $v$.lib/pathconfig for it. Files in this hierarchy will be re-created as hard links. The prefix $v$ can be chosen at the time makeml is invoked (see section 6.1)--just like $u$ can be chosen at the time CMB.make is invoked. The default for $v$ is sml. Copying the directory prevents any future CMB.make from clobbering the libraries that belong to the newly generated heap image.

Running the testml script will start the runtime system, instruct it to load heap image $v$. arch- osname, and arrange for the path configuration file $v$.lib/pathconfig to take effect. This will cause any anchor $a$ to be resolved within the $v$.lib hierarchy. Thus, the new system can be tested in a way that is completely independent from any existing installation. (Again, $v$ can be specified as a parameter to testml.)

install:

When testing has been satisfactory, the new system can be installed permamently, replacing the old heap image and its old libraries with their newly created counterparts. To do so, one should run the installml script. It will move the heap image $v$. arch- osname to ../../bin/.heap/sml. arch- osname and all stablefiles from $v$.lib to their usual place under ../../lib. It then proceeds to edit ../../lib/pathconfig (the main path configuration file of the installation) to reflect the new situation. (Library files in ../../lib that have nothing to do with the bootstrap process will remain untouched.)