[xcvb-devel] XCVB .396, now with XCVB master and slave compilation

[Faré]

One feature I added last weekend and debugged earlier this week is the
xcvb-master package.

See blurb below my signature from the README:
http://common-lisp.net/project/xcvb/doc/README.html#interactive-update-of-a-running-image-with-xcvb-master

As usual, release tarballs are below:
  http://common-lisp.net/projects/xcvb/releases/

Which leads me to my next question: according to you gentle readers,
what are the obstacles to adoption that I should focus on?

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Love doesn't scale. -- Eric S. Raymond


Interactive update of a running image with XCVB master

/xcvb/master is a small standalone Lisp file. It allows you to build
some Lisp software cleanly in a subprocess then load the results into
the current image.

When you call xcvb-master:build-and-load (which also has the
short-hand xcvbm:bnl), it will use run-program to invoke a slave XCVB
process that will drive all the compilation out-of-image then reply to
the master with a specification of files to load. The function takes
as arguments the name of a build and a flurry of options. The build
specifies what you want to update; the options precisely match those
of xcvb make-makefile.

The slave will complete the build then reply with a list of files to
load, including a TTH checksum of each file so the master can skip the
files of which the very same version has already been loaded. The
slave will do all the cryptographic hashing on its side, so you don't
have to include crypto libraries in your image -- or anything beside
the simple and short xcvb-master.

By default XCVB will include the master and provide initial
configuration of it in any build you make with the Makefile backend,
unless you explicitly specify --no-master (which really is only useful
for bootstrapping XCVB itself). Even then, you can explicitly include
it in your software by specifying a dependency on /xcvb/master, though
it might not be initially configured by XCVB if you compiled with the
--no-master flag or with the ASDF/POIU backend.

You can also include the XCVB master in an ASDF build as system
xcvb-master or load it as a Lisp file from a bare image with (load
"/path/to/xcvb/master/master.lisp") as an alternative to using
asdf.lisp to drive further compilations.

The XCVB master can advantageously replace ASDF, as it has a much
smaller footprint, doesn't pollute the current process with artefacts
of compilation or the compilation with the artefacts of the current
process, doesn't have as many threads concurrency issues as compiling
in-process can raise, and preserves determinism in the FASL files
being built.

Note that if you built your Lisp image using ASDF, either directly
with ADSF (possibly with files from our ASDF backend), or with our
current non-dependency-enforcing build, then XCVB master will
basically rebuild and reload everything using our enforcing backend;
but you can use the usual ASDF mechanisms to update your system as
usual. If you used our non-enforcing backend, you currently have to
regenerate a new image from the command-line, then use ASDF to reload
the system in your current image (we hope to provide automation for
that in a further version of XCVB).