Boost logo

Boost :

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk