Using source controlled libraries in source contro

Question

I have several projects that build reusable libraries. All these projects are under source control.

When I use these libraries in a project I simply link to the same ONE version on my local drive. However as you can imagine, this can cause problems when I commit back, and a different developer tries to clone the repository.

What is the best practice when using components also under source control? Should I include the "library projects" in the "main project" source control? Will this cause problems?

NB: The libraries take quite a few compiler directives so its almost impossible to just compile a static version and link to that. Plus I'm still developing them in parallel.

Answer 1

You have two main kind of dependencies:

• source dependencies (you need to include, within the sources of your project, source from another project),
• binary dependencies (you need to include a packaged set of files, like the ones found in a shared library).

If, when you say "I use these libraries in a project", you mean you need the binaries in order for your project to compile, then you could store said binaries in an external repository (i.e. not a (D)VCS like Mercurial, but an artifact repository like Nexus)

But if you mean you need to include sources, because you are also making some evolutions to those libraries while using them to develop your project, then Mercurial subrepos are a better fit.

Answer 2

If the libraries are under your source control, life should be easy. What I tend to do is the same as I do for different versions of third party libraries: Have different folders for different versions.

The third party library folder structure looks like this:

- General
  - Delphi
    - Components
      - LibX
        - LibX 9.2.1.3890
        - LibX 10.1.0.7151
      - LibY
        - LibY 3.6
        - LibY 5.1
    - Plugins

Each and every project defines it dependencies on specific versions of each library. Reverting back to an old version of a project, thus also reverts the dependency to older versions of the library(ies).

Now with third party libraries you generally don't have as many different versions as you can do with your own libraries, but the same principals apply. And to aid in "current development" - where you don't have a particular version number yet, you could simply have a "head" version. Then when you "release" a version of your library, just add that version's folder and adjust the project definitions that have up till know used the "head" because of parallel development, to depend on the new version number...

Answer 3

In my own experience, maintaining compatibility with libraries that you are writing simultaneously is drastically improved by using export maps to provide multiple versions of your interfaces to client programs. The best guide I know of is Ulrich Drepper's http://people.redhat.com/drepper/dsohowto.pdf