Subject: Re: [boost] Releasing Boost Dependency Analyzer 1.1
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-08-10 23:01:28
on Sat Aug 10 2013, "Jens Weller" <JensWeller-AT-gmx.de> wrote:
>> Gesendet: Samstag, 10. August 2013 um 08:10 Uhr
>> Von: "Dave Abrahams" <dave_at_[hidden]>
>> An: boost_at_[hidden]
>> Cc: boost-users_at_[hidden]
>> Betreff: Re: [boost] Releasing Boost Dependency Analyzer 1.1
>> on Fri Aug 09 2013, "Jens Weller" <JensWeller-AT-gmx.de> wrote:
>> > Some feedback:
>> > libraries.xml as a lib name source is nice, but not quite
>> > perfect. I've seen different results from maintainers.txt and
>> > libraries.xml.
>> > As maintainers.txt also libraries.xml contains duplicates, some of its
>> > library names don't fit the expectation of bcp, so I applied some
>> > fixes for this in my program.
>> > The Dependency filter is yet not perfect, especially in detection.
>> > More details about this version and the download for it at my blog:
>> > http://www.meetingcpp.com/index.php/br/items/releasing-boost-dependency-analyzer-1-1.html
>> > kind regards,
>> A bunch of dependency analysis code is checked in to Ryppl.
> Very nice to know :)
>> About a year ago I used it to make these graphs which I think are more
>> informative than the ones I see on your blog.
>> Of course, I don't remember anymore what the color coding and line
>> styles signify, but that information is probably easily extracted from
>> the source code.
> Well, you *think* their more informative, but don't remember what the
> colors are... ;)
Well, in the first one, red and green identify two strongly-connected
components, where neither library can be built without the other one
present. I pruned all leaves of the graph to increase clarity of the
dependencies that remained.
> But if ryppl wouldn't know about those dependencies, you'd fail your
Sorry, I don't know what you mean by that remark.
> For now my tool uses boost bcp as the view on the dependencies. Not
> sure if ryppl could be use to extract the dependencies for my tool.
The ryppl code extracts dependencies recorded in the CMake files of a
modularized / CMake-ified Boost.
> I'm thinking about a module doing the exporting to graphviz too, just
> currently have no time to actually write it. So currently I'm limited
> to what layoutalgorithms boost graph gives me.
Boost Graph and C++ are overpowered for this job. The Python code I
wrote processes these graphs just fine, and it was very fast to develop.
> Which is only fructerman reingold working.
> Also personally, I find those graphs with lots of long wiggly edges
> very hard to read.
How in the world do you track the straight edges in
You could always adjust the code so it told graphviz to use straight
lines, but personally I was more interested in avoiding collisions and
> And don't forget that those graphs are in my tool interactive, you can
> move nodes, and selecting a node will highlight all its connections.
I'm not forgetting because I never knew that. But what is it good for?
Anyway, if you're not interested in my code, I'm not insulted, but I
I did some very serious analytical work (which is reflected in the
shapes and colors of those graphs) when I was doing this stuff, and
I thought it would be a shame for anyone to start over from scratch.
-- Dave Abrahams
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk