[xcvb-devel] race with default object directory

[Peter Keller]

Hello,

While testing out the default object directory changes we made, I ran
into a race condition which exposed vague semantics.

Suppose we have this in a Makefile and we run it to produce the
executable.  Notice I'm using the shiny new feature of the default
directory and the show-settings command.

XCVB_OBJECT_DIRECTORY=`xcvb show object-directory`
XCVB_IMAGE=${XCVB_OBJECT_DIRECTORY}/example-1.image

# Required for xcvb to find the source registry
export CL_SOURCE_REGISTRY := ${XCVB_ROOT}//:${CL_SOURCE_REGISTRY}

# Build by having xcvb run the simple-build steps itself.
build:
    xcvb simple-build \ 
        --build "example-1" \
        --lisp-implementation ${LISP} \
        --verbosity 10
    cl-launch --lisp ${LISP} \
        --image ${XCVB_IMAGE} \
        --no-include \
        --dump '!' \
        --output example-1 \
        --init '(xcvb-example-1::main)'

In this example, example-1 in the cwd is the produced executable.

Now, we do this:

$ cd `xcvb show object-directory`
$ ls
psilord at meta:~/.cache/xcvb/common-lisp/sbcl-1.0.47-linux-x86$ ls
total 56528
-rwxr-xr-x 1 psilord psilord 28897308 Apr 28 03:42 _.image
-rw-r--r-- 1 psilord psilord      375 Apr 28 03:41 ___initial.manifest
drwxr-xr-x 2 psilord psilord     4096 Apr 28 03:42 example-1
-rwxr-xr-x 1 psilord psilord 28897308 Apr 28 03:42 example-1.image
-rw-r--r-- 1 psilord psilord      393 Apr 28 03:42 example-1.manifest
drwxr-xr-x 2 psilord psilord     4096 Apr 28 03:41 xcvb

If you notice there is stuff is not contained in the example-1 directory.

If I had two makes going at the same time, each building different things,
but happening to choose the same executable name, a collision happens
in the toplevel object-directory. A collision could always happen with
_.image depending upon which make wrote it first and which make needs
it next! Same with ___initial.manifest.

There is also some notion about the driver codes too, should they be
rebuilt for each project or shared among all projects? It must be that
they are always in a consistent state if shared.

Either way, we need to fix the above race condition otherwise people
can be in for a nasty surprise.

Maybe show-settings can take a --build which will show the setting in relation
to that build, as opposed to the xcvb toplevel.

For example:

xcvb show object-directory =>
	~/.cache/xcvb/common-lisp/sbcl-1.0.47-linux-x86

xcvb show --build "example-1" object-directory =>
	~/.cache/xcvb/common-lisp/sbcl-1.0.47-linux-x86/example-1

We need a more clearly defined place, semantics, and full path retrieval
method for any images produced by an arbitrary run of xcvb.

Later,
-pete