Using controlled source libraries in versioned projects

Question

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

When I use these libraries in a project, I just bind to the same ONE version on my local disk. However, as you can imagine, this can cause problems when I get back and another developer is trying to clone the repository.

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

NB: libraries accept quite a lot of compiler directives, so it’s almost impossible to just compile the static version and a link to it. In addition, I am still developing them in parallel.

Answer 1

You have two main types of dependencies:

• source dependencies (you need to include a source from another project in the source of your project),
• binary dependencies (you need to include a batch set of files, for example, found in the shared library).

If you say “I use these libraries in the project”, you mean that you need binaries so that your project can compile, then you could store the specified binaries in an external repository (i.e. not (D) VCS like Mercurial, but artifact repository like Nexus )

But if you mean that you need to include sources, because you also make some evolutions for these libraries when using them to develop your project, then Mercurial subrepos are better suited.

Answer 2

In my own experience, compatibility support with libraries that you write at the same time is greatly improved by using export maps to provide multiple versions of your interfaces to client programs. The best guide I know is Ulrich Drapper http://people.redhat.com/drepper/dsohowto.pdf

Answer 3

If libraries are under your source control, life should be simple. What I usually do is the same as for different versions of third-party libraries: have different folders for different versions.

The folder structure of the third-party library is as follows:

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

Each project determines its dependence on the specific versions of each library. Returning to the old version of the project, in this way, dependence on older versions of the library (s) also returns.

Now with third-party libraries you usually do not have as many different versions as you can do with your own libraries, but the same principles apply. And to help in the "current development" - where you do not yet have a specific version number, you can simply have a "head" version. Then, when you “release” the version of your library, simply add this folder with the version and configure the project definitions, which until the “head” is known due to parallel development, depend on the new version number ...