Re: [jamboost] gcc libraries order

From: Ali Azarbayejani (ali_at_[hidden])
Date: 2003-03-25 11:34:54

Volodya,

Ok, I misunderstood your comment about <library> in Req implying
"link-to" in Usage-Req. Anyway, I don't think the current implementation
works the way you seemed to imply.

So I'll wait for a specification and work from there.

I think if we want to continue a discussion of design, a concrete
specification will be a good reference point to start from.

Thanks,
--Ali

Vladimir Prus wrote:
> 
> 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
> 
> 
> To unsubscribe from this group, send an email to:
> jamboost-unsubscribe_at_[hidden]
> 
> 
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/