Re: [jamboost] Re: Improved linking mechanism

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-10-20 10:35:19

David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
> > David Abrahams wrote:
> >> I never understood the meaning of <use>. I still don't.
> >
> > <use>some_lib
> >
> > means: "grab usage requirements" from some_lib. Nothing else. "some_lib"
> > won't be linked to the target which contains this property.
>
> OK, that's very logical, thanks. It's not in the docs, AFAICT. 

I know, it's in my docs TODO. I really need to act on those issues before the 
list is longer than my monitor can show.

> I
> believe we need an index of built-in features and their meaning. I
> think these occur in several layers, and features like <use> are in
> the core layer because they have a fundamental effect on the
> operation of the build system.

Agree.

> >> > Now that you've asked, I am not sure bubble-up linking should be in
> >> > docs.
> >>
> >> Definitely not. Documenting it as a separate concept in linking.html
> >> on equal footing with "automatic" linking threw me off, for sure.
> >
> > Ok, I see.
> >
> >> Especially if the ability to write
> >>
> >> lib a : a.cpp : <use>b : : <library>b ;
> >>
> >> simply "falls out" of other information you're going to document, it
> >> would be better for people to discover it that way.
> >
> > I don't understand what's "discove it that way" means. Sorry.
>
> I mean, users can read the documentation about the meaning of <use>
> and <library>, and discover that combining them in that way produces
> the result they want. 

I see.

> On the other hand...
>
> >> I think you *should* document the behavior of lib targets in the
> >> sources of other libraries, and doing it in terms of the line above
> >> is perfectly fine.
> >
> > Okay.
>
> ...if you do the above, it will be very evident, so there's not much
> to "discover" ;-)

Okay. 

> >> IMO it also makes sense for this functionality to be somehow looked up
> >> as a property of the "b" target rather than being special-cased.
> >
> > The current idea is this: you're trying to create static lib "a" and
> > have "b" in sources. The generator for "a" cannot consume "b", so
> > "b" is returned together with whatever targets are produced for "a".
>
> Right, and... dynamic libraries can be consumed directly, so *they*
> just do the right thing as well?

Sure. 

> > The only special-casing I see here is that before "a" is
> > constructed, all <library>properties are converted into sources, so
> > that they are passed to the generator. This approach seems logical
> > for me.
>
> Fair enough.
>
> I guess you might also want a way of saying which kinds of targets
> each target type "expects" to fail to consume, so that we can report
> unintentional consumption failures. For example:
>
> expect-not-consumed STATIC_LIB : STATIC_LIB ;
>
> or something similar.

I think that we can rely on generators for this checks. If gcc.archive does 
not accept STATIC_LIB target, it will never be accepted. Or do you have 
anything else in mind?

- Volodya