<library> (Was: I'm back!)

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-10-16 01:31:02

David Abrahams wrote:
>>>However, I can't get it to build me a shared lib no matter what I
>>>do. Adding <shared>true to the requirements or the default-build has
>>>no effect.
>>
> 
> OK, I checked some things in, but it's still not working for me under
> Cygwin, because I can't get -lpython2.2.dll to show up on the command
> line. Something wrong with the <library> property. 

Actually, I intend <library> for something else. It's "dependency" 
property, and will be used to specify dependencies on other main 
targets. For "-lpython2.2.dll" we'd need something else, maybe 
<find-library> or <standard-library>?

> How is feature relevance-to-toolset implemented in v2, BTW?

Currently it's not implemented at all. The plan is simple: 'action' 
class in virtual-targets.jam has a set of properties and a name of rule 
which actually set ups actions. That name, BTW, is equal to 'id' of 
generator which created the action.

We'd change the ctor of 'action' so that it retrives the list of 
irrelevant properties for the used rule, and remove those. For example, 
you might have somewhere

flags gcc.link DEFINE : <define> ;

And then you create 'action' with rule 'gcc.link' and properties

<bison-debug>true <define>FOO

It will be determined that <bison-debug>true is not relevant for 
"gcc.link", and that property will be ignored, i.e. won't be included in
$(self.properties) for action instance.

I need to clarify one more thing. Now, virtual target has 'subvariant' 
attribute and 'path' method. However, both of them are determined by 
properties of the action that creates that target. For this reason I 
have a local mod, which removes 'subvariant' attribute from 
'virtual-target' and moves the 'path' method into target. So, action 
will be the only place which stores properties and the above will work.

- Volodya