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.
> > Do you have a specific algorithm for computing library order using
> > dependency graph.
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
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
lib a : a.cpp other_lib
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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk