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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-03-05 10:37:08

Hi Ali,

> I have three quick questions about Jam/Boost.Build (they are actually
> quick even though I've supplied a lot of verbose clarification). I am
> considering Jam/Boost.Build as a replacement for my Make-based system
> primarily for performance reasons.
>
> Boost.Build seems to have a cross-platform modular framework with
> build configurations with most of the features of my system (and some
> I don't have) but should be MUCH better performing simply because it
> can avoid the recursive make invocations...it also has better language
> constructs than Make. However, I ran across a couple of issues in the
> documentation that I could use some clarification on.
>
>
> 1 - Project IDs, Subprojects, Project Trees: Is it true in
> Bjam/Boost.Build that sub-projects must be subdirectories?
>
> (boost_1_29_0/tools/build/build_system.htm)
> "A project is a source directory tree containing at least one
> Jamfile. The root directory of the project is known as the project
> root. The root directory of a project may contain a Jamrules file,
> which contains project-specific Jam code. If the Jamrules file is
> not present when Jam is invoked, a warning will be issued."
> "Subdirectories containing Jamfiles are called subproject
> directories. Each such Jamfile describes a subproject."
>
> If so, I am very disappointed. Subprojects should be independent
> projects in their own right. In fact, in practice a subproject may
> originally be built by someone else for another purpose in a
> different location or a different code tree or an entirely different
> repository altogether...there's no reason (that I can see) why you
> shouldn't be able simply to check it out and use it as a subproject
> in a new project without having to change or relocate it.

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.

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.

> I know that it's not necessary in theory because my working system
> treats all projects equally; each project has an id (a partial path
> in a virtual tree...like Java) and one project can refer to another
> simply by its id. By default, all projects are expected to be
> checked out in a common root making them all findable with no
> additional information, but they don't have to be in the same
> root...they can be in separate locations and found via an optional
> path environment variable if not found locally.
>
> Mine is a much more flexible design than what appears by the
> documentation is designed in Boost, and I fail to see what is gained
> by the limitation of tying project trees together by REQUIRING these
> extra root files (boost-build.jam, project-root.jam,
> Jamrules)...maybe I am missing an essential point or maybe this
> isn't a requirement anymore?

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?

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

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

> 3 - May be problem with non-GCC compilers on Cygwin? Are there
> problems building with MSVC on Cygwin with bjam/Boost.Build?

I can't comment, since I'm not a Windows person. Maybe Dave can add.

- Volodya