Re: [jamboost] Three quick questions about BJam/Boost.Build

From: Ali Azarbayejani (ali_at_[hidden])
Date: 2003-03-05 11:14:44

Thanks for your quick reply...

Vladimir Prus wrote:
> 
> >
> > 1 - Project IDs, Subprojects, Project Trees: Is it true in
> > Bjam/Boost.Build that sub-projects must be subdirectories?
> 
> In Boost.Build V1, this is not possible. In V2, there situation is different:
> 
> 1 if you have Jamfile in subdir, then it's subproject, which inherits parent's
> attributes and so on.

OK, this is convenient...fine. It is useful if you can subscribe to
the structural constraint that your project is entirely self-contained
in a single heirarchy.

But, personally, I wouldn't mind being explicit even in this case. A
more consistent and flexible policy would be that a super-project
specifies IDs of all its subprojects, whether they are subdirectories
or not...they should be allowed to be physically located as sibling
directories or "distant cousin" directories as well. (see example
below)

> 2. However, if subdir also contains file called project-root.jam, it's
> entirely standalone entity. For example, you can grab entire Boost
> source tree, add it to directory "boost" at the top of your project, and
> use it.

Yes, I see. However, this is what I would like to avoid...relocating
projects. Say I already have Boost source tree somewhere else, and
I'm using it as a subproject in another project. I would like to
simply point at it and say "use packages/boost", WITHOUT adding the
source tree to the top of my project. Here is an example
illustration.

home
+- work
+- packages
| +- boost
| +- Makefile/Jamfile
| +- ...
|
+- myroot
| +- exe
| +- myexe
| +- Makefile/Jamfile
| +- ...
|
+- anotherroot
+- lib
+- alibrary
+- Makefile/Jamfile

There are three projects here.

(1) Project "packages/boost" (self-contained)

(2) Project "anotherroot/lib/alibrary" (self-contained, a useful
library)

(3) Project "myroot/exe/myexe" (depends on "anotherroot/lib/alibrary"
and
"packages/boost")

(Note that there could be other projects which use "packages/boost" or
"anotherroot/lib/alibrary", so it's undesirable to create copies of
them for each project that uses them.)

They come from three different repositories. I would like just to
check them out "as is", not try to arrange them in a heirarchy. Can
you understand the usefulness of this for code-sharing and re-use in a
diverse development organization?

> Jamrules does not exist in V2, and boost-build.jam serves quite different
> purpose --- allows to find the build system without any environment
> variables.
> 
> Can you explain what is wrong with project-root.jam?

Can you explain why it is necessary? Why aren't the directives found
in project-root.jam simply in the Jamfile (of the root project)?

(Note that I'm not clear on the difference between project-root.jam
and boost-build.jam...I think in both versions of Boost.Build there is
some .jam file that is required to be found upward of each Jamfile. I
suppose each Jamfile could have a corresponding project-root.jam, but
as you can see in the above example, there is no "project root" in
this case...the "work" directory is not part of any of the three
separate code trees.)

> 
> > 2 - Build Configurations. A Built Target of a certain Build
> > Configuration can depend on dependencies only of the same Build
> > Configuration?
> >
> > (boost_1_29_0/tools/build/build_system.htm)
> > "When a main target depends on the product of a second main target
> > (as when an executable depends on and links to a static library),
> > each build configuration of the dependent target is depends on the
> > corresponding build of the dependency."
> >
> > This is okay default behavior, but there are common situations in
> > which a different behavior makes sense, i.e. all stable
> > performance-critical libraries should always be linked "release",
> > even when the super-projects are compiled "debug" (this is a real
> > and critical requirement of one of my users).
> >
> > In my system, the default behavior is the same as Boost, but there
> > are two ways of modifying it. Say project exe/foo depends on
> > project lib/bar. First, I can specify in project lib/bar that its
> > default configuration is "release" instead of the configuration of
> > its super-project.
> 
> Boost.Build allows the same via "requirements".

cool. i need to learn the syntax.

> > Second, I can explicitly specify in project
> > exe/foo that the "release" config of lib/bar is to be linked in the
> > "debug" configuration of exe/foo (more precisely, I derive a new
> > configuration from "debug" and alter the new config, but either way
> > works for me).
> 
> Yes, this is possible as well in V2. For example
> 
> exe main : main.cpp lib/<optimization>speed ;

great.

--Ali