Just to finish out my part on this -- the reason I didn't hit the same kind of quandry you've been describing is that in the environment I used Jam for baseline builds, the user had a "build tree" where all targets lived (they got built into it directly, not later installed there), and that build tree was theirs to do with what they would. (The reason for this was that the "build tree" was actually the runnable system, so they could actually run and test things they were changing as they went, without having to do anything else except just build.)

I supplied them a path to the baseline source tree, which they NFS mounted (read-only) onto their machine, and a path to a tar-file of the latest build (corresponding to the baseline source), which they loaded onto their machine (actually, physically). Since all the targets were built directly into the build tree (according to the rules I wrote), finding the targets and using them, or rebuilding them, was a non-issue. (I hope that's clear -- it's simpler than it sounds.)

I don't know whether this sort of setup would work for you, but you might consider it, since it does work without too much trouble (now that SEARCH_SOURCE is usable this way). Although it does still have that one little ugly where people would have to pull all the Jamfiles into their local source-tree hierarchy (unlike when I did change the jam code, where it worked to find Jamfiles as well the other source tree).

Oh well, hope this helps some anyway,

Diane (dia...@whistle.com)