How to manage 3rd party libraries in a multi-configuration project

Question

Suppose you are working on some project that supports several configurations (linux and windows builds, shared/static linking, with some feature or without, etc). To build all these configurations you need different versions of 3rd party components (built with gcc or msvc, shared/static, with some specified preprocessor definitions, etc). So eventually you end up with a problem of managing all these configurations not only for your project, but for all the libraries your project is using.

Is there a general solution/approach/software to facilitate managing several different configurations of a single project?

Criteria:

• Ease of setup, i.e. how much time one would need to spend to build your project from scratch?
• Ease of management, i.e. is it hard to add new dependency or remove an existing one?
• Error proof, i.e. how often developers will break the build by changing dependencies?

So far I've tried several approaches.

1. Store prebuilt packages for every configuration under VCS.

   Pros: Ease of setup while project is small (update working copy and you are good to go). Ease of management (build library once for every required configuration). Error proof (VCS client notifies you about changes in your working copy).

   Cons: Doesn't work well for distributed VCS (GIT, Mercurial, etc.). Repository grows rapidly and eventually a simple "clone" operation will be intolerable. You also end up downloading a lot of stuff which you don't really need (i.e. windows libraries if you are working on linux). And if you are implementing library, then users of your library will inherit all these problems by integrating it in their project.

2. Store library sources instead of prebuilt packages.

   Pros: Ease of setup.

   Cons: It is extremely painful to add a new library. You need to provide build scripts and source patches for every configuration. But that is only the tip of the iceberg. Your dependencies have their own dependencies, which have their own, so on and so forth ... You have a good chance to end up with something like a Gentoo distribution :)

3. Store an archive or just a folder with prebuilt packages somewhere on the external server.

   Pros: Solves the problem... kind of.

   Cons: Not so easy to setup (you have to copy the archive manually). Not so easy to manage (you have to add each library to a server by hand). No history of changes. Not error proof, because it is easy to forget to put something on the server, or to remove something useful.

   Slightly improved approach: you can use a centralized VCS (for example, SVN) to store all 3rd party libraries, it will be easier to work with. But still you either don't have a centralized history of changes if you use it as a simple file storage, or you get a huge repository with lots of unnecessary libraries if you use it as a sub-repository.

Answer 1

When you faced with such type of problems, you have to learn and start using Configuration Management tools (besides usual technics of your SCM of choice). CM is process, and using some of Configuration Management Tools is part of this process.

Currently we have greate choice of different CM-tools, in which you can select best-fit or just preferred. From my POV, Chef is "Best Choice for Everybody", you mileage may vary