[xcvb-devel] Next on the TODO list: multiple BUILDs, search paths, etc.

[Faré]

Since the initial prototype release, I've been cleaning up a bit and
adding to the documentation, focusing notably on what's TODO next.

One topic that's at the same time relatively easy to code and urgent
is the ability to handle multiple projects that must be compiled
together.

ASDF has its infamous *central-registry*. gcc has /usr/include and
various -I flags. then there is PERL5PATH, PYTHONPATH, etc.

What should xcvb do?

I was thinking of identifying every BUILD with a URN, possibly using
xcvb: as the prefix. But how shall we map some top-level directories
to some URNs?

Any ideas on what xcvb should do? Remember that currently, xcvb takes
a xcvb-specialized lisp configuration / program as a parameter -- but
we may eventually want to also/instead have a full command-line
interface to drive xcvb from Make.

My current thoughts: XCVB at startup initializes a path from each of
the following, in order, that may either modify or replace the former:
1- builtin default, say /usr/share/common-lisp/source/
2- environment variable, say XCVB_PATH, : delimited, some magic entry
! means splice the former value
3- command-line argument, say --path, same behavior as above
4- lisp configuration, say xcvb:*search-path*, a list of pathnames.

How each pathname is interpreted is that whenever a new module is
requested, it is looked up:
1- in the current build
2- in each of the parents of the current build
3- in each of the paths specified above, from first to last (left to right).

Any comments?

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
"I've finally learned what `upward compatible' means.  It means we
 get to keep all our old mistakes."
 -- Dennie van Tassel