Re: [jamboost] gcc libraries order

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-03-25 10:38:15

Ali Azarbayejani wrote:

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

Oops. Sorry for mistake. <library> property in requiremens grabs usage
requirements and uses them when building the main target. Those
usage requirements are not recursively propagated. When you use
<library> in requirement for other library, nothing, except for grabbing
usage requirements happens (i.e. no attempt to link to the library is made).

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

No. The answer is that <library> = <uses> + some extra semantics.
This extra semantics is not used in the first case, so it is equal to

lib a : a.cpp : <uses>b ;

which is certainly not equal to <2>.

> Do you see why I think the current specification is a little loose,
> and redundant? 

It's kinda loose indeed. I was planning to document this all in detail for 
more than week, but nothing comes so far. Will try again this evening.

> And fishy?...

I had to look up this word in a dictionalty ;-)

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

I don't see any inconsistency. Usage requirements will be propagated to 
client and will mean "client links to B and uses B" there.

> 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 agree that we need to tighen specification somewhat.

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

I'm afraid the current specification is nonexistent. The usage requirements
mechanism was suggested by me long ago and was considered convinience.
It now turns out that it is quite important, but the docs/specification are 
not up-to-date. Let's try to fix it.

> 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

Did I say that?! I think this is just a bad as the previous version. It works
now, but I'd say it's never to be used. 

> lib a : a.cpp : <uses>b : : <library>b ;
> # ...and is equivalent to this

I don't think so. The <library>b in requirement does not affect usage
requirements. 

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

Ok, I'm gonna try. Don't want to do it in a hurry, so will respond tomorrow.

- Volodya