Re: [jamboost] Wrapping up new design

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-04 12:22:47

----- Original Message -----
From: "Vladimir Prus" <ghost_at_[hidden]>

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

Welcome back!

> [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?

No. One problem we currently have is that:
1. Lots of work is done for each toolset with which a target is built
2. When there are lots of targets in a Jamfile (e.g. status/Jamfile), this
work is done over and over. Even when there's only a single toolset
involved, it's noticeably slow.

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

No, it's just a question of what requirements it places on program
structure. The overhead might not be a neccessary consequence of direct
construction of the dependency graph, but it seems harder to avoid that way.

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

Okay, I like where you're going here.