Re: [jamboost] gcc libraries order

From: Ali Azarbayejani (ali_at_[hidden])
Date: 2003-03-21 12:49:41

Vladimir Prus wrote:
> 
> The setting above is what I'd expect. The question is how to order the
> libraries. If 'DirectSubLibs' is "a" and "b", I assumed something like:
> 
> lib a : a.cpp : <library>b ;
> lib b : b.cpp ;
> 
> would result in 'b' put before 'a' on the linker's command line. Now, I'm
> having problems defending this approach --- yours looks better. So, please
> you <dependency> feature. In future, then <dependency> will be renamed to
> <using> we'll have
> 
> lib a : a.cpp : <using>b ;
> lib b : b.cpp ;
> 
> which is quite intuitive.

Ok, I will implement a solution based on <dependency> for now, but I
would like some clarification as to what the syntax is supposed to
mean, because it seems a little complicated or redundant. The
following is my understanding of the current syntax. (Note I'm using
"<uses>" instead of "<dependency>" below because I understand the goal
is to change the name.)

CURRENT SYNTAX
----------------------------------------

lib b : b.cpp : : : <include>. ; # a target using b finds its headers
here

lib a : a.cpp : <library>b ;	# ?? does this actually do anything?

lib a : a.cpp : <uses>b ;	# a can find b's headers (thru b's usage-req)

lib a : a.cpp : : : <library>b ; # target linking to a also links to b

lib a : a.cpp : : : <uses>b ; # if a target depends on a, it can also
# find b's headers (this is imo usually
bad sw
# design, because the user should explicitly
# depend on b if it wants to use its headers,
# or its other usage-req's for that matter)

exe e : e.cpp : <library>a ;	# link to a. isn't this the same as:
# "exe e : e.cpp a ;" ?

exe e : e.cpp : <uses>a ;	# can find a's headers (and other usage-req)

exe e : e.cpp : : : <library>a ; # ?? makes no sense at all, no ??

exe e : e.cpp : : : <uses>a ; # ?? conceivably has a use, but
probably not ?

QUESTION
----------------------------------------

Conceptually, dependencies on libs should be quite simple

<A> If lib "a" depends on lib "b", "a" simply needs to be able to
find the public headers of "b".

<B> If exe "e" depends on a lib, "e" needs both to find the public
headers of the lib and to link to the lib and all its
dependencies, recursively.

It seems as though this could be expressed more simply like this:

lib b : b.cpp : : : <include>./include/b ;
lib a : a.cpp b : : : <include>./include/a ;
exe e : e.cpp a ;

or, alternatively, like this (I don't quite understand the
difference between specifying a library as a "source" versus as a
"requirement").

lib b : b.cpp : : : <include>./include/b ;
lib a : a.cpp : <library>b : : <include>./include/a ;
exe e : e.cpp : <library>a ;

In either case, why can't "a" acquire the usage-requirements of "b"
(find its headers) by virtue of "b" being a source (or,
alternatively, by virtue of "b" being a <library> requirement).
Similarly, why can't "e" acquire "a"s usage-requirements and link to
"a" and "b" simply by virtue of "a" being a source (or <library>
requirement) of "e"? 

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.

Maybe I am misunderstanding the intent of the <library> feature. It
seems currently to be a low-level synonym for "<link-to>" rather
than a higher-level statement of a lib dependency ?

Like I said, I'll carry on with <dependency> for now, but I'd like to
be clear on the syntax.

Thanks,
--Ali