From: Ali Azarbayejani (ali_at_[hidden])
Date: 2003-03-05 10:18:10
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.
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?
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. 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).
Does Boost.Build provide for either or both of these means of
modifying the configuration tree in a straightforward sensible way?
3 - May be problem with non-GCC compilers on Cygwin? Are there
problems building with MSVC on Cygwin with bjam/Boost.Build?
"Windows 9x users should note that the bjam executable will produce
command lines too long for command.com to handle."
"Cygwin users can use the cygwin executable to work around Windows 9x
command line length problems, but only if they are using cygwin-gcc
compiler (other windows compilers don't play particularly well with
Thanks in advance,
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