Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-04 10:30:41

David Abrahams wrote:
> Sorry if things have been a bit quiet lately. I'm just trying to keep
> all of these balls in the air at once...

Hmm.... looks like you've decided to give Boost.Build a speedup right on the
very first day of the year :-) Due to that I've been slow in catching with
the discussion.

> 3. The system reads the Jamfile in the invocation directory. Jamfiles
> contain mostly /declarative/ rule invocations. Declarative rules
> build data structures describing targets (and other things,
> e.g. toolsets in toolset description files). Of course a Jamfile
> may also import modules and invoke rules that do more heavy-duty
> work. There are several important reason to use declarative rules
> in Jamfiles. First, the current system which constructs a
> dependency/action graph as each descriptive rule is read is quite
> inefficient for large projects.

Could you elaborate? Is building the graph that hard compared with rules
invocations? Are there any actions that could be avoided with declarative
semantics? (However, I'm agree with declarative Jamfile nature, so this
questions isn't really important)

> OK, so I've tossed off most of the work of the build system in one
> sentence. The rest of this document deals with that in more detail.

> Determining the subproject requirements
> project.project ( project-id : requirements * : default-build * )
> project.jamfile-location( root-to-jamfile )
> project.source-location( root-to-source )

I have been experimenting with project semantics recently:
1. We'd need a way to find out where the parent project lives, so that we can
grab requirements. By default it can be the parent directory of the one where
Jamfile is located, but an explicit way to give parent location is needed as
2. There's a problem about jamfile-location. Consider

project.project foo/bar ;
project.jamfile-location foo/src/bar/build ;
some other rules.

Here, "some other rules" supposedly won't work unless Jamrules is included.
It easy in this case. Suppose that "project.jamfile-location" is not used.
How are we to understand that jamfile location is determined by the project
name and include Jamrules before "some other rules"? Having thought about
this, I suppose a different syntax for project declaration, similar to named

project.project foo/bar
: jamfile-location foo/src/bar/build
: requirements <gcc><cxxflags>-frepo

This allows to solve the problem above (and looks neat to me, besides). Also,
project.project is better imported to Jamfile's module, to make interface

> Generating Targets
> Target names given by users in a Jamfile aren't, in general, the
> names of targets that will actually be used by the build system,
> since elements such as subvariant grist come into play. In order to
> keep the system usable, however, ungristed names are "claimed" by
> the system for NOTFILE targets which correspond to the user's
> notion of what should be built. When multiple subvariant builds
> have been requested these NOTFILE targets will depend on several
> built target files.


- Volodya


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at