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
> 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
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
> grab requirements. By default it can be the parent directory of the one
> Jamfile is located, but an explicit way to give parent location is needed
> 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
> 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
> name and include Jamrules before "some other rules"? Having thought about
> this, I suppose a different syntax for project declaration, similar to
> 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).
> project.project is better imported to Jamfile's module, to make interface
Okay, I like where you're going here.
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