Boost logo

Boost-Build :

From: bmosher_at_crosswinds_dot_net (bmosher_at_[hidden])
Date: 2002-02-09 17:19:29

As I continue studying the feasibility of switching to jamboost, I am
faced again with another challenge. I thought I had resolved most of
the issues, but in presenting my case to the full-time build engineer
who will be responsible for rolling this out, a few questions

Our development group is divided into multiple product lines that
deploy our core technology into various end-user applications. Each
product line depends on the core subtree, so imagine if you will a
multi-product source tree that looks something like this:

top-level repository root <=== potential project root
+---Apps <=== potential project root
¦ +---Editor
¦ +---EditorSDK
¦ +---Viewer
¦ +---ViewerSDK
+---Core <=== potential project root
¦ +---MemLib
¦ +---NetworkLib
¦ +---OpsLib
¦ +---Tests
+---Demos <=== potential project root

Our developers are divided into teams that maintain each product line
and a core group of algorithm engineers whose sole job is to improve
the core technology. We use Perforce as our source control system
which makes it very easy for individual developers to create their
own limited views of the repository based on their particular role in
the development organization. For example, a typical algorithm
engineer will map their client view to include the Core subtree as
their project root. So their local tree might have the Core directory
as a top-level folder of their $HOME directory. The rest of the tree
would not be present on their local drive:


Is it feasible to set up jamboost in such a way as to allow the
project to be rooted dynamically? Ideally with little intervention
from the developer -- something as simple as running jam in their
local root directory perhaps? I can foresee 3-4 places in the tree
that this would be desirable. In the above diagram I have identified
these directories with "<===" arrows. Is it possible to have
multiple "project-root" jamfiles in the tree to facilitate this? What
are the potential problems with this scenario? From my initial
research, I believe there are a couple of possible hurdles:

1. Where to put/How to include the Jamrules file? It seems that
setting the $TOPRULES environment variable could address this.

2. The "subproject" rule hard-codes the relative path back to the
root. If each subproject Jamfile were to use the "project-root" rule
instead, this may resolve the issue. I am unclear what the full
ramifications of this would be. I do think that this may introduce
the possibility of namespace collision in the $ALL_LOCATE_TARGET
build tree. If I understand correctly, all main targets would need to
be uniquely-named to prevent build target binaries from overlapping.

3. Using the "project-root" rule would cause the library <lib>
dependencies to be relative to the root directory. If the root
changes, this would invalidate the relative path embedded in the
subproject jamfiles. This problem seems a bit more difficult to
solve. Perhaps specifying the paths using variables could address

I have a feeling that these issues can be resolved, but I would like
to do this in a way that fits in with the "intent" of the existing
system. I would like to avoid going against the grain of what is
already in place. Also I expect that this may have already been
addressed by others previously. Is there an accepted approach to this
problem of multiple nested project-roots, or is the system intended
to be "hard"-rooted and then refer directly to the leaf targets using
the "subinclude" rule? I have noticed that this is how the boost
libraries have their Jamfiles laid out.

Much thanks as always,
--Brian Mosher


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at