Re: [jamboost] Re: Spec draft

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.

Yes.

> 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 needed...you 
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 
propagation.

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