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

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-16 09:34:26

Vladimir Prus <ghost_at_[hidden]> writes:

> David Abrahams wrote:
> > 
> > Those are OK, but I think you ought to
> 
> "we ought to"? ;-)

Uh, sorry :(
I had already considered, and didn't come up with anything ;-)

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

Yeah, well since it might well not be "standard", I think find-library
or search-library or path-library (scary symmetry!) would be
better. And given recent discussions on this list about GCC, it might
be neccessary to represent "link to this one statically" or "link to
this one dynamically", somehow...

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

Ah, that sounds familiar to me now.

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

I didn't even know about that file! I was looking in targets.jam.

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

I agree in principle.

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

OK, I'll look at virtual-target.jam

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