Announcing boost dependency analyzer
Hello to the boost community, I'd like to announce the release of a small tool, that allows you analyze the dependencies in boost. It is based on bcp, requirement is that you have bcp build and well a version of boost to analyze installed. Simply select the boost directory (the tool also might find BOOST_ROOT) and the location of bcp, and the tool will start. This will take a little time, depending on your machine, on my multicore intel ist 90 seconds - 2 minute. The tool will store this information into a database, so that with the next start, this will be a lot shorter. The tool allows to analyze the dependcies of a single boost library, but also of all of boost. Its build with Qt for the UI and processing part, and uses boost graph for the layout. Full information + download you'll find at my blogpost: http://www.meetingcpp.com/index.php/br/items/boost-dependency-analyzer.html Current Issues: What libraries might be missing? I'm reading the libs from maintainers.txt, which isn't all the boost libs. For example, lexical_cast is missing, and function_types is twice in there. (C&P error or missing library?) So far Windows is supported, linux support planned and improving, currently ownly the (beta) binaries for linux available. kind regards, Jens Weller
"Jens Weller" <JensWeller@gmx.de> writes:
Full information + download you'll find at my blogpost: http://www.meetingcpp.com/index.php/br/items/boost-dependency-analyzer.html
This is interesting to me--I wanted to look into shipping certain boost libraries separately in Fedora. Currently we have a huge boost-devel that ships the whole boost/ subtree. That made sense back in 1.33 timeframe, but it makes less and less sense with every new release. Unfortunately the Boost dependency graph is as huge a hairball as I was afraid :-/ [Actually, more useful to me would be something scriptable. All that GUI stuff, frankly, is juts a distraction to me--though it does produce nice graphs :) (BTW, did you use graphviz, or is that custom-coded?).] Do you plan to make this tool open source? Thanks, PM
Hi, thanks for the feedback. Yes, dependency graph for boost is quite large... I think with boost in git and modules available, this is going to improve.
Well, not yet. I think about using boost graph graphviz export, thats one of the planned features. The layout is currently based on boost graph layouts algorithms. There is a /data directory after you've run the first analysis, with a SQLITE database, might be helpful for you.
Do you plan to make this tool open source?
Maybe yes ;) A feature release on github as GPL is planned. Not sure when. busy times. kind regards, Jens Weller
On 23/07/13 12:08, Jens Weller wrote:
This is probably the biggest problem of this tool. AFAIK bcp doesn't distinguish between header dependencies, source dependencies, link dependencies, test dependencies and documentation dependencies. Therefore you end up with way more than what you actually care about.
I found 6 libraries (+ lexical_cast) which aren't covered through maintainers.txt, most prominent mpi and system.
Therefore you end up with way more than what you actually care about.
Thats why I want to add filters, most of the library views are already now readable. Filtering will allow to filter after name or categories (Headers,libs, doc, test, etc.) kind regards, Jens Weller
On Tue, 23 Jul 2013, at 12:08 PM, Jens Weller wrote:
Looking at the file's history it was inserted in the wrong place the first time, and then was later added in the right place, apparently not noticing the existing entry. Sometimes the idea of what is a library, or part of a library, is quite fluid. Lexical cast is often seen as part of 'conversion', similarly 'math' is sometimes considered a collection of libraries itself. You might have better luck considering the new modules, as some will contain multiple libraries, and at least one will contain none, but still be a dependency. 'maintainers.txt' was never intended to be a list of libraries, but a list of who's responsible for various parts of boost. A better list of libraries is possibly the one used for the website: http://www.boost.org/doc/libraries.xml To get the list for a specific version you need to filter based on 'boost-version', and the optional 'boost-min-version' and 'boost-max-version' tags. After modularization the idea is to store this data within the modules, although the complete details will have to be stored somewhere, so it might be possible to keep that file up.
Well, as I'm based on boost bcp, I'm kind of viewing boost through its eyes. I've done some research in the bcp code to find out, how its reading, but couldn't find a single source for library name mappings. Looking for an easily readable source, maintainers.txt is a good source distributed.
See, thats the problem for my tool currently, its based on the directory you select. Is libraries.xml part of the distribution? I could not find it under %boost_root%/doc. kind regards, Jens Weller
participants (5)
-
Antony Polukhin -
Daniel James -
Jens Weller -
Mathias Gaunard -
Petr Machata