Re: [jamboost] Project/Subproject tree layout

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-02-10 14:00:17

> Is it feasible to set up jamboost in such a way as to allow the 
> project to be rooted dynamically? 

Firstly, the precise meaning of "rooted dynamically" isn't completely
clear to me. Secondly, the answer to your question may well depend on
whether we're talking about the current Boost.Build V1 or the upcoming
V2. You can read about relevant V2 design decisions at
http://www.boost.org/tools/build/architecture.html. As for Boost.Build
V1, the location of the root relative to any subproject directory is
fixed, but there's no reason that all subproject
directories need to be available on a given machine.

> Ideally with little intervention 
> from the developer -- something as simple as running jam in their 
> local root directory perhaps?

I'm not sure what you have in mind here. It almost sounds as though
you want to establish a local root directory by running Jam once with
special options (?). There's no way to do that with V1, and I don't
think I'd consider it a high-priority interface for V2 since it's
pretty simple to drop a project-root.jam file wherever you want it.

FWIW, even with V1 you don't need to build from the project root
directory -- that's part of the point of having subprojects: you can
invoke Jam in an individual subproject directory, and only the targets
defined there will be built.

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

Why do you really want to do this? Is it too much of a burden to keep
the directory you've labeled "top level repository root" around? It
does result in at most log(N) extra directory levels, but in your case
it looks like that number is 1, and it might even be zero.

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

You seem already to be proposing a (very complicated) solution before
really making clear what problem you're trying to solve.

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

I assume that by "hard-rooted" you mean that the relative locations of
subprojects to the project root is fixed. Yes, that's the intention of
Boost.Build V1. As I've said, though, the project root is just there
to make a convenient place to build everything from, and to stash
common user-defined rules. You can invoke subinclude from any Jamfile.

-Dave