Re: [jamboost] Wrapping up new design

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.

[snip]
> 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.
[snip]

> 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 
well.
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 
parameters:

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

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

Right!

- Volodya