2025-12-07

managing dependencies in software development

structural realities that shape dependency strategy

c requires every library that uses another library to relink against all transitive dependencies.
a library linked against one version of another library cannot be safely combined with a library linked against a different version of that dependency.
these constraints generate linker hell: version divergence forces rebuilds even when the direct interface has not changed.

for example, glibc and musl cannot depend on each other. binaries linked against one cannot be mixed with components linked against the other.
composition across libc boundaries requires complete recompilation of the entire dependency tree.
similar incompatibilities appear when low level runtimes provide mutually exclusive abis.

deep dependency chains increase rebuild frequency when any upstream segment changes.
copy importers attempting to inline external code may face cascading rewrite requirements if nested dependencies are not flattened.
binary level composition is constrained by abi coupling; source level composition is constrained by symbol layout and internal reference structure.

many libraries included anywhere: simple but prone to conflict when intermediate libraries include one another.
importing and localizing libraries: source is copied into the project namespace to avoid external versioning issues.
incorporating code portions: create a thin helper library containing only the subset of another library actually required. the code duplication can increase maintenance burden or require manual copy of the code for bugfix updates

eliminating internal depth simplifies copy import.
function level flattening: extract required functions of another library into a helper artifact so multiple modules share a consistent minimal subset.
file level flattening: include large files even when only one binding is needed; maintenance cost stays limited to the actually used interface.

scripts can import files and rewrite internal references to local namespace identifiers.
this avoids manual maintenance while allowing version pinning, deterministic builds, and isolation from upstream structural changes.

git submodules: users must run update or sync operations; dependency on repository layout and continued repository existence.
submodules do not ship code by default; distribution requires extra steps or vendor scripts.
hybrid patterns exist: track a pinned commit via submodule, then copy or vendor the corresponding code into the main tree.
manual copying remains a valid choice when maintainers prefer controlled compatibility selection over tracking upstream evolution automatically.

dependencies that are difficult to acquire or build (for example when any part of the systems becomes incompatible over time). this may fully prevent the usage of a program.