What do you depend on?

There seems to be lot of interests in slimming down all kind of libraries lately. Anyone trying to bring his great application or framework to a mobile platform maybe? For other reasons I was interested in the information passed to compilers and figured that having this information available can of course also be used to write tool to analyze dependencies. Given that I’m writing my thesis currently and need a bit of distraction every now and than I started working such a tool. By the way, it was a nice opportunity to play a bit with the Boost Graph Libraries. So, without further ado I present: C++ Dependency Analyzer.

The tool reads a file with compile commands and creates a dependency graph of it. Yes, I am aware that CMake can create a dependency graph but that one is limited. Also, for other reasons I’m interested in other information you can get from a build too, but well that’s long term. Anyways, a graph of a complete project (e.g. kdepim) in itself is not very useful because its huge and cluttered. Therefore I started working filtering options. In the image you see the subgraph of kdesupport containing only the dependencies of akonadiserver. All this is in a very early state. However, colleagues of mine put heavy pressure on me to stop working on my thesis and make it available. Thanks Volker, Keven!

So, if you’re sure you want to play with it:

git clone git://gitorious.org/cpp-dependency-analyzer/cpp-dependency-analyzer.git

Short howto

  1. The source contains a script called: scripts/g++-wrapper.pl. Modify the contents of it (esp. the path) to meet your system.
  2. Set the CXX environment variable to let it point to the script.
  3. Build the project for which you want to create the graph. Make sure you use -j1 otherwise the resulting file will get borked.
  4. Start the depency analyzer and create a new project. Point the build session file to the file generated by the make.

Limitations

As said, the whole thing is in very early stages. The UI you see for filtering is *only* functional for the targets part of it. That is, you can double click a target in the tree and update the graph. This will give you the dependencies for the selected targets only. The rest of the filtering is only UI. The current level of filtering is hard coded to leave out any source files and any object files, though both are part of the underlying graph.

The actual information comes from a file which contains lines existing of: the current working directory and the arguments passed to the compiler. I only wrote a parser for g++ and tested it only with g++ 4. It has been used already to create the graphs for kdesupport and kdepim though.

It is really slow for large graphs.

Nice-to-haves

Some ideas to make you work on this application…. eh to document what I’d like to add to the application somewhere in the near future.

I hope to find some time to make the filtering a bit more complete. I already started working on the ui for it, but it still needs to get integrated in the graph logic. Especially useful would be to add duplicate edge filtering, because duplicate edges really clutter the graph at the moment.

A wrapper which stores the same information in an unborked way when using multiple compile jobs would be nice too, to reduce the time needed to generate graphs. However, this is a low priority thing for me.

Exporting graphs to svg would be nice too. This should be trivial, thus boring, thus don’t expect it too soon.

Disclaimer

I’m quite convinced that this application has a great potential for maintenance and packaging purposes. But again (I can’t repeat it enough I guess) its in a very premature state at the moment. Expect failures, crashes, your cat eaten and who knows what more which you will have to solve yourself. Add to that that I’m very limited in time currently so feature requests will only be accepted in the form of patches.

Last but not least I’d like to thank our stl and boost guru Marc Mutz for helping me to get started with BGL!

This entry was posted in Uncategorized and tagged , . Bookmark the permalink.

12 Responses to What do you depend on?

  1. M. Fioretti says:

    “In the image you see the subgraph of kdesupport containing only the dependencies of akonadiserver”

    which image, sorry? There’s none in this post

  2. Rodrigo Fernandes says:

    You might want to double check the images (they 404)

  3. Alex says:

    In which ways do you think the CMake dependency generator is limited ?
    It’s free software, so you could change this too :-)

    Or, maybe cmake can generate something for you which would help your project ?

    Alex

  4. Bertjan says:

    Hi Alex,

    Honestly I didn’t really looked into that option very deep, so if I did CMake short in unreasonable ways, let me apologize for that first. I only had a short look at the results of the  –graphviz switch. That one showed a limited graph (i.e. only targets).

    I’m interested in the precise info passed to the compiler. So if CMake would be able to produce a sequence of commands it would perform and store that in a file similar to what I use now, that would be awesome.

    Why do or didn’t I add that myself? Well for me that info is a means not a goal, I can get it in the simplified way I do know with near to 0 effort and its enough for my current needs. However, it would really speed up the process of showing a graph if CMake can produce that info without having to do a complete build.

    Cheers,

    Bertjan

  5. Volker Lanz says:

    Thanks for the great looking tool.

    Built it and tried it with Partition Manager, but only got so far as to set up a new project and pick the base dir and the compile session file. The app then aborts with:

    ASSERT: "!outputFile.isEmpty()" in file /home/vl/src/cpp-dependency-analyzer/src/parsers/gppparser.cpp, line 139
    Aborted

    The compile session file is not empty.

  6. Bertjan says:

    Hey Volker,

    Have a look at: http://gitorious.org/cpp-dependency-analyzer/cpp-dependency-analyzer/blobs/master/src/parsers/gppparser.cpp#line135

    As you can see, there’s a comment in there stating: “TODO….”. I didn’t implement the case you’re triggering yet. Its not about having an empty build session file. The case you have is something like this probably, you have a line in the build session file that doesn’t specify the outputFile:

    some/path/ myfile.cpp

    I.e. there is no output file (like myfile.o) specified. The parser looks for -o and than sets the outputFile variable to the next argument. E.g.

    some/path/ myfile.cpp -o myfile.o

    But when its not specified some default name is used (a.out?). If you look at the code, you see that there is a qDebug() just above. Have a look at that debug line and try to figure out what would be needed.

    This should be enough info to create a fix I think. I’d be glad to receive a patch solving this issue =:)

    Cheers,

    Bertjan

  7. maninalift says:

    I was interested in an idea like this: Implementing some sort of dependency clustering to find things that were almost but not quite separable modules and so allow you to find things that perhaps should be modules. One could identify what is preventing modularisation and consider whether removing that blockage would improve design. Could be interesting to run such a thing on large libraries.

  8. Paul Fee says:

    Hi,

    You might also like to look at:
    http://domseichter.blogspot.com/2008/02/visualize-dependencies-of-binaries-and.html

    This draws dependency graphs for DSOs, not the same as extracting build time dependency information, but useful for runtime dependency graphs.

    Thanks,
    Paul

  9. Bertjan says:

    Interesting indeed! That would be useful to add to the application. The problem with just printing out pictures is that it becomes unusable as soon as the large becomes too large. Adding this information and offering more advanced filtering options will make it easier to do in depth analysis of your projects dependencies. My app currently stops at the explicitly linked libs.

    I’ll sure have a closer look at this at some point.

  10. vzfcjkolx says:

    rUa1Q5 kaopstqfdogl, [url=http://njwnomwaggjl.com/]njwnomwaggjl[/url], [link=http://djvryvpgkwia.com/]djvryvpgkwia[/link], http://wetqssbbzikn.com/

  11. Anonymous says:

    Why not make as a KDevelop plugin?

  12. Ian Monroe says:

    Funny that your break from your thesis is something that would probably make a reasonable undergraduate thesis. :)

Comments are closed.