Re: [jamboost] Toolsets: 'flags' rule

From: David Abrahams (dave_at_[hidden])
Date: 2002-11-30 16:36:36

I don't know how long I've been sitting on this reply, but here it is.

Vladimir Prus <ghost_at_[hidden]> writes:

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

On closer inspection, I guess you're right. The only other option I
could imagine would be to use a separate object for each "flags"
invocation. It's not a convincing win to do that, though.

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

OK.

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

Yep, this makes total sense to me.

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

Great! Can we rename "use requirements" to "usage requirements"? Since
"use" can be a verb, it comes out sounding ambiguous.

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

Not quite. Maye you mean it's the name of a class instance.

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

Ah. So do we need a notion of "target" features, whose values are
replaced with the targets they identify at some point in processing?

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