Nice little development tool

This year I’ll be working on Pidgin for Summer of Code, and I’m hoping to replace GtkIMHtml with Webkit.

As always, learning the source code takes a significant amount of the time, and so I created this small little tool to help me in the process. I had started this a while back, and completed it today, and thought I’ll share it.

What it does: after building the project, you have lots of “.o” files lying around. These “.o” files have very useful information about the symbols that it exports, and the symbols that it uses from elsewhere. This immediately gives me a very clean way to track dependencies. (The other way is to use header files. Well… )

As a second step, I don’t like cyclical dependencies. I personally like to keep cyclical dependencies to a minimum. In fact, while trying to understand code, it makes more sense to think of an entire strongly connected component of modules as one single component.

So my code just finds the SCC graph, and then topo sorts them to display the final dependency graph very neatly. It gives a quick overview of the code layout. (And can probably be used as a tool to remove cyclical dependencies.)

Here’s a git repo: http://opc.iarcs.org.in/public/repo/arnold/depgrapher.git (Quick git HowTo: git clone <url>)

(For the contest coders: this is written in C, and uses n^2 algorithms everywhere. :P Messy code.)

What I’d like to do: I’d like to display the DAG GUI-ily—in the way gitk shows the commit graph. (I could just take graph drawing code from git, but I don’t have the time.)

Is there already a tool to do this? If not, contributions welcome.

Advertisements

3 Responses to Nice little development tool

  1. Shreevatsa says:

    Yeah, I saw that you’re working on SoC… congratulations!

    I’m not sure I understand what your tool does — doesn’t Doxygen already do the same thing? [If you haven’t used doxygen: I’ve found it very useful to understand source code… if you turn on all options, it can show not only graphs of dependencies for each header file, but also call graphs for *each* function (and also where it’s called from). On something like the Pidgin source tree it might take an hour and a GB to generate all the graphs, but it’s worth it!]

  2. Arnie says:

    I have seen the Doxygen style graphs: and have used the ones for libpurple a lot when coding for rediffbol-prpl :) However, the point of this was more to find the strongly connected components in one quick step. I immediately get an idea that if I change so-and-so module, nothing else depends on it/or it does not depend on anything.. and stuff like that. For example, I found out that the component I’m supposed to work on is part of a large SCC. :) Once I know this, I can look back at the Doxygen graphs to figure out what is exactly causing such dependencies. (EDIT: also doxygen shows dependencies among header files, and not among source files. The former is useful for writing plugins, the latter is useful for hacking the code.)

    Now, for a well written project, using the dependencies from header files or from actual symbols exported should be identical. Symbols seemed like a more easier way to do it, and also works well for badly written code. :) Symbols should also work for any type of programming language as long as it creates .o files.

  3. Arnie says:

    but guess what: I just realized I could’ve used graphviz to do all my graph code. Bah. This post needs deleting. :)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: