Boost logo

Boost-Build :

From: Ali Azarbayejani (ali_at_[hidden])
Date: 2003-06-20 09:16:41

Vladimir Prus wrote:
> Ali Azarbayejani wrote:
> I had explained that already, I think. Did you seen the email with the
> following code:
> for s in sources:
> source_targets = []
> TargetSpec t = targets.find(p.value())
> source_targets += t.generate(build_properties)

okay, i'll take a look. i missed this so i wasn't certain what you meant.

> I think I was saying that already. They *are* used polymorphically! User can
> write:

i'll have to think about this some more. i've been focused on the
Target as the main polymorphic entity.

>>The current system doesn't generate an explicit dependency graph with
>>all the "virtual-targets" acting literally as nodes. There is, of
>>course, some equivalent representation of dependencies inside each
>>"virtual-target" and its associated "action", but the graph is not made
>>explicit and abstract in type so that one could, e.g., easily traverse
>>the graph to compute the link-line library dependency order.
> Do you have a specific algorithm for computing library order using dependency
> graph.


> Also, do you think that if library "a" should come before "b" in link
> line, there should be *dependency* from "b"'s targets to "a"'s target. I
> believe the last statement is not true.

Yes, I absolutely do. It doesn't get more dependent then that.

> Imagine
> exe main : main.cpp a b ;
> lib a : a.cpp ;
> lib b : b.cpp : <uses-symbols-from>a;
> Now, "a" should come before "b" in link line, if you're linking "main". But,
> there should be no dependency from "b" to "a". IOW, if I run

(I think you mean "b" should be before "a".)

> bjam b
> then "a" should not be compiled -- it's really not needed for anything.

The compiled binary is not needed, but "a" is certainly
need the headers. How does "b" know where "a"'s headers are?

I say that "b" depends on "a". What this means for the "compile" action
is that "b" can find "a"'s headers. What this means for the "link"
action is that the final link product must link to "a".

In general, just establish that "b" depends on "a" (abstractly),
creating a dependency link from the "b" node to the "a" node in the
dependency graph (i.e. Target graph). Then each action benefits from
this dependency in its own way.

Philosophically "compile" can look at all its immediate dependencies and
grab their <include> usage-requirements and "link" can traverse its
dependency sub-tree, find all libraries that it directly or indirectly
depends upon, find the correct order, and add them to the link line.

Practically, however, we implement this philosophy using property

In summary, if "b" uses symbols from "a", "b" depends on "a". The
system should be smart enough to figure out whether "a" should be
compiled or not.

>>A motivation for the Target base class is for explicit representation of
>>the dependency graph and abstract application of the "realize" function
>>(which amounts to "actualize" now that we've determined that "generate"
>>isn't really polymorphic among Project, MainTarget, and FileTarget).
> Did we? IMO, it's is polymorphic among Project and MainTarget. And with my
> scheme for FileTargetSpec, it polymorphic for it, as well.

Like I said above, I'll have to think about this and re-consider.


Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at