# Static Libs Do Not Modular Make

DevFeed: [Static Libs Do Not Modular Make](<https://devfeed.tech/articles/static-libs-do-not-modular-make-28617.md>)

Original publisher: [Read original article](<https://upcoder.com/18/static-libs-do-not-modular-make>)

Published: 2017-09-23T13:12:00Z

Content type: article

Language: en

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

Topics: [Library](<https://devfeed.tech/topics/library.md>), [modules](<https://devfeed.tech/topics/modules.md>), [C](<https://devfeed.tech/topics/c.md>), [C++](<https://devfeed.tech/topics/c-plus-plus.md>), [implementation](<https://devfeed.tech/topics/implementation.md>), [Software](<https://devfeed.tech/topics/software.md>)

Tags: [build](<https://devfeed.tech/tags/build.md>), [c](<https://devfeed.tech/tags/c.md>), [c-plus-plus](<https://devfeed.tech/tags/c-plus-plus.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [libraries](<https://devfeed.tech/tags/libraries.md>), [modules](<https://devfeed.tech/tags/modules.md>)

## AI overview

The article argues that splitting C/C++ source files into statically linked libraries does little by itself to improve modularity and can significantly increase dependencies. It discusses organizing code into libraries, defining interfaces, and hiding implementation details as additional aspects of modular design.

## Source excerpt

A cautionary tale about statically-linked libraries, as generated by C/C++ build tools. As a project accumulates features, and complexity, it gets harder to understand exactly what's going on, and to find your way around the source code. You need to find some way to organise the code and try and keep things manageable. A common idea, in this situation, is to group some source files together to split out as a static library. I'm going to argue that this actually does very little, in itself, to increase modularity, can have the effect of significantly increasing dependencies, and is maybe not such a good idea, after all. Break it apart? So yeah, when something gets too big to work with, it makes sense to try to break it into pieces. Given a whole bunch of source files to work with, we probably want 'pieces' bigger than individual source files, and that means grouping source files together. Perhaps there are files that can be grouped together by theme (e.g. a bunch of source files related to 'geometry'). Or perhaps some kind of layered decomposition is possible (e.g. we can identify a bunch of 'core' source files). And then we can separate this group of files from the rest of our source code by putting them in a library. Making things modular Wiktionary defines 'modular' as follows: Consisting of separate modules; especially where each module performs or fulfills some specified function and could be replaced by a similar module for the same function, independently of the other modules. Libraries are a classic archetype for a software module, and splitting our code into libraries already kind of nails the first part of that, (the bit before the semicolon), right? The bit after the semicolon is probably also worth consideration, but we can tweak the code to better address this bit, incrementally, later on, by firming up the interface, hiding implementation details, and so on. Having our source code 'consisting of modules' already feels like a good start, and a step in th