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
> 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
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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk