# Automatic Object Linkage, with Include Graphs

DevFeed: [Automatic Object Linkage, with Include Graphs](<https://devfeed.tech/articles/automatic-object-linkage-with-include-graphs-28618.md>)

Original publisher: [Read original article](<https://upcoder.com/19/automatic-object-linkage-with-include-graphs>)

Published: 2018-05-31T13:33:00Z

Content type: tutorial

Language: en

Sources: [Thomas Young](<https://devfeed.tech/sources/thomas-young.md>)

Topics: [Code](<https://devfeed.tech/topics/code.md>), [C](<https://devfeed.tech/topics/c.md>), [C++](<https://devfeed.tech/topics/c-plus-plus.md>), [Library](<https://devfeed.tech/topics/library.md>), [Graphs](<https://devfeed.tech/topics/graphs.md>), [Testing](<https://devfeed.tech/topics/testing.md>)

Tags: [c](<https://devfeed.tech/tags/c.md>), [c-plus-plus](<https://devfeed.tech/tags/c-plus-plus.md>), [code](<https://devfeed.tech/tags/code.md>), [graphs](<https://devfeed.tech/tags/graphs.md>), [libraries](<https://devfeed.tech/tags/libraries.md>), [library](<https://devfeed.tech/tags/library.md>), [testing](<https://devfeed.tech/tags/testing.md>), [unit-testing](<https://devfeed.tech/tags/unit-testing.md>)

## AI overview

The article presents a custom build process for sharing C and C++ source code across multiple build targets. It uses include-relationship graphs to determine which object files belong in each link operation, reducing unnecessary dependencies associated with broad static libraries.

## Source excerpt

In this post I describe an alternative approach to sharing source code elements between multiple build targets. It's based on a custom build process I implemented at PathEngine for our C and C++ code-base (but the core ideas could also be relevant to other languages with compilation to object files). We'll need to enforce some constraints on the way the source code is set up, notably with regards to header file organisation, but can then automatically determine what to include in the link operation for each build target, based on a graph of include relationships extracted from the source files. The resulting dynamic, fine grained, object-file centric approach to code sharing avoids the need for problematic static library decomposition, and the associated 'false dependencies'. Motivation We need to work with a bunch of different build targets, at PathEngine. There's a run-time pathfinding dll, for example, but also a 3D content processing dll, a 3D testbed application, and so on, with a lot of source code shared between these different targets. The code was originally split into a set of (internal) static libraries, for this purpose. based on things like theme (e.g. 'Geometry.lib') or application layer ('PathEngine_Core.lib', 'PathEngine_Interface.lib'). Different targets could then share common source code by sharing these static libraries. This worked, as far as it goes, but something didn't feel right. The libraries weren't particularly modular, for one thing, and just felt like big old bags of object files that didn't really reflect the actual structure of the underlying code. A bigger problem was that, for any kind of prototyping work, I ended up having to link in a big chunk of the PathEngine source code, even where only some small part of this was really required. Unit testing was also difficult to setup, for a similar reason. Since throwing out the static libraries and switching to an alternative approach (as described in this post), prototyping and unit test