You are in a maze of twisty little #include statements, all alike

While sussing out the IPv4->IPv6 in the current code base, I’ve run across the problem of not knowing enough about the entire product to be able to easily track the include dependencies.  I’ve been using a neat tool that tracks these down and graphs them directly in Visual Studio.  Probably one of the best $40 I’ve ever spent.

In the tool diagram, all the drawing entities are “live”.  Square boxes are user header files and diamonds are system includes.  You can hover the mouse to see the full path, open the file, etc.  If you hover over a line connected two files, it will display the file position (line number) where one includes the other.

The most general use of the tool during building is to see which other files will rebuild if one is touched.  There’s also a “build impact” line graph, which they describe thusly:

“The build impact is essentially an approximation of the cost of including a file, relative to the total cost of compiling a base source file. The estimation is based on token counts from the preprocessor, as a compiler-centric equivalent to the popular ‘lines of code’ metric. Its primary use is in discovering build bottlenecks and determining why some files take a long time to compile. “


CygNet NET.H analyses

Here’s a high-level view of the include graph for CygNetSourceSupportNetNet.h (click to zoom in)

Click to view at full size

Here’s a slightly more useful zoomed-in view (click to zoom in)

Click to view at full size


Leave a Reply

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

You are commenting using your 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