CMake logo
The CMake logo, licensed under CC BY 2.0

Library dependency graphs in CMake

Notes published the
1 - 2 minutes to read, 358 words
Categories: build system, c, c++
Keywords: build system, c, c++, cmake

One of the main advantages of using popular programs instead of reinventing the wheel every time is the integration with other programs.

A very useful feature of CMake, is that together with graphviz it is possible to create diagrams that show the relation between libraries without writing a single line of code:

cmake -S <source dir> -B <build dir>;
mkdir <build dir>/deps;
cd <build dir>/deps;
cmake --graphviz=deps <build dir>;
mkdir <build dir>/deps-svg;
mkdir <build dir>/deps-png;
for i in *; do :;
  dot -Tsvg -o "<build dir>/deps-svg/$i.svg" "$i";
  dot -Tpng -o "<build dir>/deps-png/$i.png" "$i";
done

As .svg files are XML files, it is also possible to parse them. Of course, it is not necessary to generate both the .png and .svg files, one is sufficient.

The main advantage of having a visual representation of the dependency graph is that it makes it easier to reason about side effects when working on a library.

It also makes it possible to answer easily a whole series of questions, without looking at the code

  • Are there circular dependencies?

  • Are two libraries somehow linked together?

  • Are there libraries that are used too much?

  • Are there libraries that are not necessary anymore?

  • Do libraries have too many dependencies?

  • How risky is upgrading a library, what are the possible pain points

  • If a library changes, what components do we need to test and adapt

While it is also possible to answer all those questions by looking at the CMake files, in practice it is not that easy.

Build files are not always declarative, and the logic is normally split over multiple files.

Thus generally one should rebuild by hand the graph (which might depend on the platform, build parameters, and other factors), which is an error-prone process.

The visual representation on the other hand gives an easy-to-understand overview, albeit of a single configuration.

The textual representation (encoded in the .svg files) can even be used for doing some automatic validation.

Do you want to share your opinion? Or is there an error, some parts that are not clear enough?

You can contact me anytime.