Re: [jamboost] Toolsets: 'flags' rule

From: David Abrahams (dave_at_[hidden])
Date: 2002-11-11 15:37:13

Vladimir Prus <ghost_at_[hidden]> writes:

> I'm about to implement the V2 version of "flags" rule, and there's
> my vision of it. On the whole, I'll retain the V1 interface, with
> the only change. Instead of
>
> flags tools-name variable-name condition .....
>
> I'll use
>
> flags rule-name variable-name condition .....
>
> Note that every build action in V2 is associated with a rule that
> sets this build action up and those rules have nice names like
> gcc.link. We'll just specify flags on per-rule basis:
>
> flags gcc.link CFLAGS <debug-symbols>true : -g ;
>
> To allow flags that apply to all rules for toolset, we'd allow
>
> flags gcc GXX-VERSION <version> ;
>
> to apply to each rule in "gcc" module.

That's pretty interesting!

One thing I've been thinking for many weeks now is that we need some
way to do "module inheritance". My thoughts are a little bit vague,
but it seems to me that toolsets really fit into this general
scheme. See extends-toolset in V1.

There are a few not-neccessarily-mutually-exclusive ways to interpret
this:

1. Like Java, where a module defines a class and that's all there is
to it.

2. The module is a singleton, so you never need to do anything
explicit to build a new instance, and the module can be handled
directly.

3. Well, I think I had a third thought, but it now escapes me ;-)

Something like this could help simplify modules like virtual-target,
which has only one class. Currently, getting help on a virtual-target
function is very long-winded:

bjam --help virtual-target.virtual-target.actualize

-- 
David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution