From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-03-05 10:37:08
> 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?
> "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
> 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
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
> "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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk