Re: [jamboost] Toolsets: 'flags' rule

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-11-12 03:15:09

David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
> 
> 
>>Vladimir Prus wrote:
>>
>>>I'm about to implement the V2 version of "flags" rule,
>>
>>Partly implemented, see toolset.jam. However, it would be nice if
>>somebody takes this over. Dave, do you have anything in your V2 task
>>pipeline?
> 
> 
> Unfortunately, I still have to work on this request of yours:
> Which I will try to do today.

Ok, let's finish that first.

>>Basically, there are three missing bits:
>>
>>1. Using
>>
>> flags gcc {some var} ...
>>
>>to catch all rules in "gcc" module is not supported.
> 
> 
> Looking at your implementation, I'm a little nervous about dumping all
> of those .flags definitions into the toolset.jam namespace. The way it
> worked in v1 was a hack; It really seems like the best place for these
> things would be on the Boost.Build target object (whatever we're
> calling that, as opposed to the Jam target object where they end up
> eventually).

.flags variables are needed in some form, I believe. You'd need to be able,
given a rule name, to find out what variables need to be set and what
conditions/values are. The scope of toolset module seems the best place.

> So "set-target-variables" really ought to be part of the
> method which creates Jam targets from Boost.Build targets.

I.e. the part of 'action.actualize' or 'virtual-target.actualize'. Hmm...
now it's called from 'action.actualize'. If we make 'set-target-variables'
a method in 'action', it would need to access the set of
variables/conditions/values for the rule -- i.e. you'd need another method
in 'toolset.jam'. I don't think it's any way better, but it's not a strong
opinion.

> 
> 
>>2. If there are any dependency property
> 
> 
> 
> Ach! I really need a glossary. I keep forgetting what the various
> terms mean. boost_build_v2.html just says "do we need it?"

Yes, I realized we need it but did not told anybody. As per previous docs,
dependecy feature specifies a main target. For example, you might have

exe nm_estimate
: nm_estimate.cpp
: <library>i18n
;

Here, <library> is an dependency feature. Before, the exe will be build,
the main target "i18n" will be found and build. Say we'll get virtual target
V. Then, when invoking generators, the property set will include <library>V
in it: i.e the name of main target will be replaced with generated virtual target.
How generators use this property is not specified. For example, "exe" would just
link this library.

To illustate why dependecy properties are usefull, consider another example:

exe nm_estimate
: nm_estimate.cpp estimate ;

lib estimate
: paths.cpp
:
:
: <library>utils # it's use-requirements slot.
;

Here, "estimate" requires "utils" library, but we don't want "nm_estimate"
to mention that library explicitly just becuase it's used in implementation
of "estimate". What happens here is that when "estimate" is generated, "utils"
will be generated as well. Then it will be propagated to nm_estimate (because
it's use-requirement), and so nm_estimate linking would include utils, without
channging "nm_estimate" declaration. I don't know any other way to achieve this.

If you're not yet bored, there's another detail. Use requirements on dependency
features are propagated to main targets that use them. For example, "utils" might be
external library. It exports certain include paths.

lib utils
: utils.cpp
:
:
: <include>/1/2/3 # use-requirements
;

In this case "<include>/1/2/3" will be propagated to "estimate" and will be use
when compiling "paths.cpp". No need to add includes explicitly.

>>, then by the time
>>that property arrives to toolset.set-target-variables, then
>>value of the property is the instance of 'virtual-target' class.
> 
> 
> The value of the property is a class instance? I'm quite confused by
> that notion.

Is the explanation above enough? The point is that it's target id for user. But
before the generators are run, it becomes a class instance. It's just easier to
work with already generated virtual targets than with target ids.

- Volodya