Re: [jamboost] gcc libraries order

From: Ali Azarbayejani (ali_at_[hidden])
Date: 2003-03-24 17:10:15

Vladimir Prus wrote:
> 
>
> > lib a : a.cpp : <library>b ; # ?? does this actually do anything?
> 
> No, this has no effect.

...But, hold on...then he sayeth the following:
>
> Usage requirements are propagated from sources, and "dependency"
> features. Both <dependency> and <library> are "dependency" features.
> The difference from
> 
> library a : a.cpp : <library>b ;
> 
> and
> 
> library a : a.cpp : <uses>b ;
> 
> is very simple. The former grabs usage requirements and is supposed to link
> to 'b'. The latter only grabs usage requirements.

So, which is it? Does a <library> property in Requirements have no
effect or does it grab usage req's and specify the need to link to b?

If the latter, as you say here, the following two statements are
equivalent:

<1> lib a : a.cpp : <library>b ;
<2> lib a : a.cpp : <uses>b : : <library>b ;

Correct?

(Although, I'm not sure <1> actually works; <2> definitely does.)

Do you see why I think the current specification is a little loose,
and redundant? And fishy?...For one thing, it doesn't seem right that
<library> means one thing as a requirement and a different thing as a
usage-requirement. (As a Req it says "I link to B and I use B", as a
Usage-Req it says "My client links to B".)

This came up in trying to implement the gcc library dependency
order...because there are (at least) two ways of specifying that
symbols from one library depend on symbols from another library.
Currently my implementation grabs the <uses> (a.k.a. <dependency>)
properties from the action of each library target to determine which
other libraries it is dependent on.

This works fine for me because in all my libraries I use the canonical
form <2> above

lib $(LibID) : $(Sources) : <uses>$(SubLibs) : : <library>$(SubLibs)

However, if other people use other ways, my current implementation
won't work for all of them. In order to implement a reliable routine,
I need a sharp specification of exactly how to specify library
dependencies...if there is more than one way, I need to know exactly
what they are intended to be.

I do not have the experience with the specification and design process
that you guys have, so I can't evaluate on my own whether the current
specification is indeed looser than it needs to be or whether there
are concrete reasons for the current somewhat redundant syntax for
<library> and <uses>/<dependency>.

Vladimir Prus wrote:
> 
> > Surely <uses> (a.k.a. <dependency>) has other uses and should still
> > be a feature in its own right, but it seems to me that expressing
> > library interdependencies should be more straightforward than is
> > currently the case. Please explain if I am misunderstanding
> > something.
> 
> The problem with putting dependecy library in sources is that it creates
> illusion that library is being linked in, while it is not --- and we don't
> want that, in general. I think that's the primary reason.

But putting <library> property in Requirements creates the same
erroneous illusion as putting it in Sources!

exe e : e.cpp b ; # e links to b (this is approved)
exe e : e.cpp : <library>b ; # e links to b (this is approved)

lib a : a.cpp b ; # you don't like this
lib a : a.cpp : <library>b ; # but this is approved
lib a : a.cpp : <uses>b : : <library>b ;
# ...and is equivalent to this

To proceed with the gcc library order bug fix, I'd like to see a
comprehensive spec for the meaning of putting a library

<1> as a source
<2> as a <library> property in Requirements
<3> as a <library> property in Usage Requirements
<4> as a <uses>/<dependency> property in Requirements
<5> as a <uses>/<dependency> property in Usage Requirements

for both "lib" and "exe" targets. (I think if you try to do this you
will find the current implementation is both redundant and
inconsistent.)

--Ali