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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-10-16 09:15:51

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

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

Two approaches:
1. Require that any used standard library is declared (not nice, I think)
2. If value <library> of library does not refer to main target, treat it 
as name of standard library. This seems too fragile.

I think I'd like a special feature, only with a shorter name than 
"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.
> 
> 
> This sounds like it's happening too late. Two virtual targets may end
> up being identical due to the removal of irrelevant properties.

No. The current scheme is based on the fact that it's sometime hard to 
avoid creating two virtual targets with the same properties, but it's 
easy to detect two equivalent virtual targets. Therefore, *all* created
virtual targets are passed through 'virtual-target.register', which 
return previously registered equivalent target if there is one.
That's why you can specify the same cpp file as source for two main 
target and have it compiled only once, in the current code.

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

What's in virtual-target.jam:50 that you have?

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

Say that you have a virtual target which an action assigned to it. The 
action with have a set of properties. The virtual target will have 
'subvariant' which will be equal to the actions properties, sans free 
and incidental ones. This functional dependency is just unnecessary -- 
why keep the same data in two places?

If you don't see a problem, there's not need to try to find it. I'll 
just commit my change tomorrow.

- Volodya