on Sat Aug 10 2013, "Jens Weller" wrote:

...

Gesendet: Samstag, 10. August 2013 um 08:10 Uhr Von: "Dave Abrahams" An: boost@lists.boost.org Cc: boost-users@lists.boost.org Betreff: Re: [boost] Releasing Boost Dependency Analyzer 1.1

...

on Fri Aug 09 2013, "Jens Weller" 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-anal...

kind regards,

A bunch of dependency analysis code is checked in to Ryppl.

https://github.com/ryppl/ryppl/tree/develop/scripts

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.

http://f.cl.ly/items/343N460u3b3039091C0g/deps.pdf http://f.cl.ly/items/0v201A0A33152G1u0u0v/deps.pdf http://f.cl.ly/items/3V2I3A103K1Y45113s3w/source-deps.pdf http://f.cl.ly/items/2r2Z1E3X1o1m2k0N321G/boost-all-deps-reduced.svg

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

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 http://www.meetingcpp.com/tl_files/blog/bda/boost154_libxml.png ? You could always adjust the code so it told graphviz to use straight lines, but personally I was more interested in avoiding collisions and obscured details.

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