Project/Subproject tree layout

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 
surfaced.

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
+---Phase1Demo
+---Phase2Demo

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:

$HOME
+---Core
+---MemLib
+---NetworkLib
+---OpsLib
+---Tests

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 
this?

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