Knitschi / CMakeProjectFramework

A C++ project infrastructure.
MIT License
2 stars 1 forks source link

Change the project repository structure to allow arbitrary subdirectories on the package level #18

Open Knitschi opened 4 years ago

Knitschi commented 4 years ago

The currently enforced structure <build-project-dir>/src/<module_package_dir> does not allow having multiple module-packages in one module repository. We also have the constraint that all modules in a deployment-package must be at the same version. Additionally we want to follow the doctrine that the commits in the repository are the single source for all versions.

All constraints together limit us to only allowing one module per deployment-package. This ticket is about removing this limitation.

We want to extend the cpfAddPackages() funktion to allow package definitions in the packages.cmake file in the form

set( CPF_PACKAGES
    EXTERNAL <deployment-package-dir>/x/y/<module_package_dir>
    # or
    EXTERNAL <single-package-dir>
)

In the second scenario the <deployment-package-dir> and the <module-package-dir> have the same name. It shall be possible to have an arbitrary number of directories in between the <deployment-package-dir> and the <module_package_dir>.

The name of the <deployment-package-dir> shall be the only source for the deployment-package-name. This is the name that will be used in package managers to retrieve a binary package and as a part of binary archive files. This will also be the name of the CMake export set and the targetnamespace for the all targets that are exported by the module packages.

The name of the <module-package-dir shall be the only source for the module-package-name. This is the name of the main target in a module-package. It also appears as the first directory in the C++ #include statements.

This ticket should also implement the mechanism that derives the deployment-package-name and the module-package-name from the relative path in the CPF_PACAKGES variable and propagates them to the install commands etc. We also need to make sure that package config files are only generated once per deployment-package.