|
Boost-Build : |
From: David Abrahams (gclbb-jamboost_at_[hidden])
Date: 2003-06-23 08:50:47
Vladimir Prus <ghost_at_[hidden]> writes:
> Ali Azarbayejani wrote:
>>
>> 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.
I don't think Ali's changing the meaning. The issue is what each tool
considers the abstract entity "a" to be.
>> 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.
A reasonable point-of-view, IMO.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
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