Abusing the word "library"

Question

I see a lot of questions, both here on SO and elsewhere, about "maintaining common libraries in a VCS". That is, projects foo and bar both depend on libbaz, and the questioner is wondering how they should import the source for libbaz into the VCS for each project.

My question is: WTF? If libbaz is a library, then foo doesn't need its source code at all. There are some libraries that are reasonably designed to be used in this manner (eg gnulib), but for the most part foo and bar ought to just link against the library.

I guess my thinking is: if you cut-and-paste source for a library into your own source tree, then you obviously don't care about future updates to the library. If you care about updates, then just link against the library and trust the library maintainers to maintain a stable API.

If you don't trust the API to remain stable, then you can't blindly update your own copy of the source anyway, so what is gained?

To summarize the question: why would anyone want to maintain a copy of a library in the source code for a project rather than just linking against that library and requiring it as a dependency?

If the only answer is "don't want the dependency", then why not just distribute a copy of the library along with your app, but keep them totally separate?

Answer 1

The use of vendor branches to control 3rd party dependencies is discussed in some depth in the Subversion book. As I understand it, the basic advantages are guaranteeing a stable API and uniformity of libraries for all developers, and the ability to control custom modifications in house in the same versioning system.

Answer 2

On the project I'm working on right now, we've got the main code (which is in one Subversion project) and a host of assorted libraries from various places that are in their own Subversion modules. The Visual Studio solution maintains separate projects for each of them and links them together at the end. If we were working on Unix or similar OSs, we'd do the same thing.

The only downside I see is that I sometimes forget to update one of the libraries that changes more frequently, and my code doesn't compile until I notice that. If we had the libraries in the same module, then we wouldn't have that problem. (Not that I'd ever do it that way. The gains in flexibility and the ability to use different libraries with different main projects are just too great.)

The API is a red herring here: either it stays the same or it changes, and if it changed we'd have to update the main code either way. So is the question of source vs. binary libraries (either we compile them with the main project, or we don't).