From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-01-29 10:07:03
David Abrahams wrote:
> > Since the new build system will support building multiple projects
> > simultaneously, there comes a question of interaction between them.
> > For example, two different project-root.jam files can declare different
> > with the same name, to be used by Jamfiles in corresponding projects.
> That part shouldn't be a problem. Each project-root.jam should be a module
> (they can be distinguished with appropriate grist). Similarly, all Jamfiles
> should be modules.
Sure, this is how I indent to make it.
> If we want we can auto-import the rules from a project's
> project-root.jam into all of its Jamfiles.
In fact, I propose a rule in proejct module which will add names to the list
of rules that should be injected in Jamfile modules. This rule, however, need
to track which project-root.jam has invoked it.
> > What is
> > even worse, they can call rules in some modules, for example to declare
> > new target types or generators or to configure something.
> In general, toolset configuration (and the like) should happen in
> user-config.jam or site-config.jam. As far as declaring new target types is
> concerned, I think that should be rare. We can either ask users to qualify
> their new target types with a project-id, or we can do it ourselves,
> > An ideal solution would
> > be if all modules that can be configured from project-root.jam or
> > Jamfiles separate information that came from different projects. Is it
> > workable?
> Probably, but I'm not sure we want to do that for every bit of
> configuration info. For example, a list of what compiler versions exist and
> where they're located doesn't seem like project-local data to me.
Okay, the most important bits are project-specific rules and
targets/generators. I'll support the former, and support for the latter can
be considered at the time of they implementation. Good.
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