Organizing library dependencies

I've noticed that there seem to be two approaches to linking: a flat and a hierarchical way.

Let me illustrate with two examples:

• A Visual Studio solution can contain multiple projects with one of them being the main project. My usual approach is then to add all required libs to the main project and none to the other projects. I like this because that way I don't get "multiple definition"-linker errors. I don't know if this approach has an official name so I'll call it the flat way.

• On the job our team works on a Linux-based traffic generation application. The build system uses Automake. When looking through the makefiles I noticed that each library specifies the libraries it requires (in the noinst_LIBRARIES variable). Each of the开发者_运维知识库se libraries can in turn specify their dependencies. This leads to a tree-like structure. So I call it the "hierarchical approach".

What are the best practices for this? It doesn't seem often discussed.

It usually comes down to static vs shared libraries.

If you use static libraries, then the main program must usually (always?) be linked against every library that it depends on, either directly or indirectly, hence a flat linking structure.

For shared libraries (or DLLs in Windows), each library bundles up its own dependencies, so the main program only needs to be linked against the libraries it depends on directly, leading to a graph structure.