Dependencies between boost libraries

Hello, I was curious to know wether there was somewhere available a graph of dependencies between boost libraries ? Best regards, -- Loïc

Loïc Joly wrote:
Hello,
I was curious to know wether there was somewhere available a graph of dependencies between boost libraries ?
No, but the bcp tool can almost do what you want - in report mode it will output a dependency analysis for a specific library or header, see http://www.boost.org/tools/bcp/bcp.html HTH, John.

John Maddock wrote:
Loïc Joly wrote:
Hello,
I was curious to know wether there was somewhere available a graph of dependencies between boost libraries ?
No, but the bcp tool can almost do what you want - in report mode it will output a dependency analysis for a specific library or header, see http://www.boost.org/tools/bcp/bcp.html
I'll just point out that things are more complicated than the 'answers' provided by bcp. As an example, date_time depends on serialization, but only if you actually include specific date_time serialization headers. Since bcp just mechanically traces dependencies it can't *know* that if you don't want to user serialization that dependency and any that serialization pulls in goes away. Jeff

Jeff Garland wrote:
I'll just point out that things are more complicated than the 'answers' provided by bcp. As an example, date_time depends on serialization, but only if you actually include specific date_time serialization headers. Since bcp just mechanically traces dependencies it can't *know* that if you don't want to user serialization that dependency and any that serialization pulls in goes away.
Right, the answer to the question depends upon your definition of "depends on". Generally it's best to ask this question of a specific header rather than a whole library (which pulls in testing and example program dependencies). bcp also has a scan mode that will scan *your code* for Boost dependencies, but even then you may get misleading results - see the shared_ptr example in the docs for an explanation. It's really annoying when the simple things turn out to be hard isn't it? :-) John.

John Maddock a écrit :
Jeff Garland wrote:
I'll just point out that things are more complicated than the 'answers' provided by bcp. As an example, date_time depends on serialization, but only if you actually include specific date_time serialization headers. Since bcp just mechanically traces dependencies it can't *know* that if you don't want to user serialization that dependency and any that serialization pulls in goes away.
Right, the answer to the question depends upon your definition of "depends on".
Generally it's best to ask this question of a specific header rather than a whole library (which pulls in testing and example program dependencies).
Well, in fact, my goal is event more fuzzy : I would like not only that the question could asked in terms of library, but also that the answer would be given in terms of library. I tried the current program, I could get thousands of relations between files. I would have been interrested in some information such as : mpl -> serialization -> date_time thread -> serialization My goal would be to get a graph that can be handled by a human brain, with a reasonable number of nodes. This could also be useful if in the future, boost libraries are released individually, and not all together.
It's really annoying when the simple things turn out to be hard isn't it? :-)
It sure is. -- Loïc
participants (3)
-
Jeff Garland
-
John Maddock
-
Loïc Joly