Allow using the same dependency in different versions.

[Knitschi]

For very large projects it must be possible to have different versions of a library in the dependency tree at the same time. If this is not allowed, all clients of the library must be updated at the same time when the library version changes. This does not scale. Allowing multiple versions of one library at the same time allows updating one client at a time in non global steps.

• To allow this the package directory names have to include the version number in order to allow multiple parallel packages. This would require an automatic mechanism that adds the git-submodules instead of the currently used manual maintanance.
• Does hunter/cmake support multiple target versions at the same time? This is required before the problem can be solved.

[Knitschi]

If we add the package version to the package targets name and the package directory, we can have multiple versions of the same package in one build-project. The problem with this is, that the includes in the code need to be updated to the new version, when we link to a new version of the package. However this can be done with a search-and-replace and we should be able to provide a script for updating the version of a depended on package.

[Knitschi]

In order to support the semantic versioning and library update mechanism on linux, we should have the real package files installed under /-/bin etc and parallel the symbolik links to the binaries /bin ...

This allows installing multiple versions of the developer packages at the same time, because installed headers will not be overwritten. At the same time the semantic versioning and update mechanism is supported via the parlallel symlink-tree.

[Knitschi]

To support compatibility between package versions, we can try reducing the version digits in the package/target names. The machanism for adding packages must support this.

[Knitschi]

After further thought I came to the conclusion, that supporting parallel package versions in the source tree is not practical.

If we add the version to the include dirs, we need to make massive code changes for each commit, in order to change the includes to the new version. This could be avoided by adding another direcory level to the source tree like Sources/<package>-<version>/<package>. However we can remove the need for this feature if we simply choose our inlined packages in a way that no two versions of one package are required. This seems to be the most practical solution.

However ist still must be possible to have imported packages in more then one version to limit the scope of package updates in the whole code-base. This will probably require the find_package() calls to be located in the packages CMakeLists file and some mechanism is required that automatically updates that version in the build-project that owns the package.