Re: [jamboost] Toolsets: 'flags' rule

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-12-02 02:34:26

David Abrahams wrote:

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

That was my though too. Classes are overkill in this case.

>>>>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
[...]
> 
> Yep, this makes total sense to me.

Excellent! I've realized this is not described in detail in the docs, so I'll 
move this description there.

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

Hey, you've just come up with the term I like myself! I did not like
"use requirements" for the same reason as you, but knew no
better alternative. Consider this done.

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

Yes, it's the name of a class instance. I thought it's the same as class 
instance, though.

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

I don't yet see a clear distinction between "dependency" and the proposed
"target" features. No problem with adding them, but let's wait for a feature
which must be "dependency" but not "target".

- Volodya