Re: [jamboost] <library> (Was: I'm back!)

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-16 08:02:28

Vladimir Prus <ghost_at_[hidden]> writes:

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

Those are OK, but I think you ought to consider ways to make the
equivalent of "-l" easier for users to write, since they will have to
do it often. Maybe we ought to find a way to make these standard
libraries act like main targets, somehow?

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

This sounds like it's happening too late. Two virtual targets may end
up being identical due to the removal of irrelevant properties.

> I need to clarify one more thing. Now, virtual target has 'subvariant' 
> attribute and 'path' method. 

I see neither one in the code.

> However, both of them are determined by properties of the action
> that creates that target. 

I'm completely lost. What does this mean, and why would this be a
problem?

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

-- 
David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com