Re: Project/Subproject tree layout

From: bmosher_at_crosswinds_dot_net (bmosher_at_[hidden])
Date: 2002-02-10 22:52:22

Dave,

> Firstly, the precise meaning of "rooted dynamically" isn't
> completely clear to me.

A better description of the question might be "Will the Boost.Build
system allow you to cd to an arbitrary directory of the tree and
build all the targets defined there and below in its subtree?"

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

So far I have only looked at the current Boost.Build system. The V1
design is already a big improvement over the internal system I'm
hoping to replace. I will take a look at the new system docs though
to get a better idea of what it will offer.

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

No, I just meant that the developer could jam from whatever spot in
the tree that makes sense for them and build everything below that
spot.

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

This works fine at the individual directory level. It would be nice
though to allow individual subtrees to build in the same fashion --
our source tree has more depth to it than the sample diagram I
posted. What I'm running up against is that Boost.Build Jamfiles seem
to fall into one of two categories, either they define the root of
the tree or they define a leaf node. Is there a way to define a node
that can aggregate the child subprojects that lie in the subtree
beneath it? (You mention 'subinclude' at the bottom of your 
message, and I think that's the answer I need to this question...)

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

I'm not sure that I'm in a position to answer this as I'm trying to
fit into the existing practice at our shop. This question arose when
I was going over the Boost.Build functionality with our build
engineer. Truthfully, the current nightly build system does works
from the top-down. It's the individual developers that we'd like to
accommodate. They currently use msvc ide dsp's to do their work and
often pull down just the subtree of interest to them. Getting them to
switch to jam looks to be a challenge and we're hoping to be as
flexible as we can to minimize organizational resistance. Maybe we
can get them to maintain the structure from the top-level when they
checkout, but it's hard to say. The tree is currently deeper than my
simplified diagram indicated. I personally don't mind keeping the
top-level directory fixed.

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

Hmm, based on this last statement, it sounds as though I could easily
define intermediate Jamfiles to do this aggregation. They would do
nothing but subinclude the subprojects below it. Then I guess the
only problem would be keeping the root directory fixed. Seems
straightforward enough. If we can abandon the need to remap the
client root, this would work, correct?

Am I on the right track here?

--Brian Mosher