[xcvb-devel] 0.550

[Faré]

I haven't made a formal release of xcvb in a while, and don't even
know if the release scripts work, but Peter Keller and I have been
hacking at XCVB to make it more usable.


Most notable changes:

* We've made a simple, serial, standalone backend, so you don't need
to have "make" installed to run XCVB. Probably matters a lot on
Windows, a bit on Macs. It also requires less user configuration.

* Peter Keller has made for extremely more useful debugging output
when running XCVB in verbose modes. Now it's easier to figure out what
XCVB is trying to do, and why, and what's breaking.


Portability:

* We distinguish between valid implementations for building XCVB
itself, and valid targets for XCVB.

* Valid implementations are SBCL, CCL, CLISP, though we mostly use
SBCL and the other two sometimes bitrot. To be tested.

* Valid targets that are tested to work include sbcl, ccl, clisp, scl on Linux.

* Valid targets supposed to work but not really tested include SBCL
and Allegro for Windows, cmucl on Linux, maybe Lispworks Pro on either
Linux or Windows.

* Broken targets include CCL on Windows, GCL, cormanlisp, lispworks
personal, ABCL, XCL and ECL.

* Backends other than the simple standalone backend, have not been
tested in some time, and have probably bitrotten: Makefile, ASDF,
POIU, forking standalone backend.


Testing:

* Now that we have good run-program support, I've started writing test
cases in a pure-lisp test system. Just spawn a slave xcvb, and check
it did its job right.

* The previous, shell-based, testing system, probably started
bitrotting while not being used.

* Unhappily, most tests are still written in the old shell-based
system and need be converted. Which is why I'm not even sure our other
backends still work...


Notable changes:

* I've created a bridge so you can write an XCVB build, and load it
from ASDF (assuming XCVB is installed and supports your
implementation). No need to maintain to build systems - just adopt
XCVB. Could be made even easier, but for now, you create a wrapping
.asd file in addition to your build.xcvb.

* I've merged the master into the driver, so there's a one-stop-shop
for XCVB support into your Lisp image. It includes such goodies as
warning control during compilation or a portable run-program wrapper
so you can extract the result from external commands as e.g. a string.


Our next priorities:

* Get ECL as a valid target.

* Fix CCL on Windows -- hopefully they will fix
http://trac.clozure.com/ccl/ticket/858 -- or we'll work around it.

* Have a "reverse slave" mode, which runs universally by having the
master process do all the compilation work, ASDF style, for
implementations with no command-line or expansive command-line
invocation (ABCL, I'm looking at you).

* Migrate more tests to our new test infrastructure, and revive other backends.

* Make our efficient parallelizing backend more robust and usable.

* Support dumping of executable programs, a la cl-launch or buildapp.


Is anyone still interested in XCVB? A good way to help would be to
move tests to be run by Lisp instead of shell.

Also, your feedback on what should be our priorities to have you
switch from ASDF to XCVB would be welcome. What are the non-starters?

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Die, v.:
        To stop sinning suddenly.
                - Elbert Hubbard