Re: [jamboost] Re: Spec draft

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-23 07:10:10

Ali Azarbayejani wrote:

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

OK.

> > Do you have a specific algorithm for computing library order using
> > dependency graph.
>
> Yes.

Probably, it would be better if you tell it ;-)

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

Oh... I think you're changing the common definition of "dependency". In all 
build tools, dependency from "b" to "a" means: if "b" is to be created, then 
"a" is to be created before it. What you describe is a slightly, but 
distincly different thing, which may cause confusion. For example, it's 
already confused me.

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

I understand your idea, but "dependency", IMO, is not appropriate word here. 
I'd say that each main target has a list of other targets that it *referres 
to*. Note also, that you cannot get away with just "dependency", because 
there are different types of dependency. For example, in future we could 
have:

lib a : a.cpp other_lib 
: <uses-generated-headers-from>another_lib
<use-buildable-tool>whale 
;

there are three references to other main targets, but they should be processed 
in completely different ways. In other words, each "dependency" link should 
be annotated with a property. This, in turns, means that difference between 
storing all those links in a property set, and storing them as separated 
edges in some graph, is really minor.

- Volodya