Put CPFCMake and CPFBuildscripts into one package.

[Knitschi]

Motivation Initially the python and cmake code where seperated into two packages. The CMake code however expects the directory structure that is enforced by the python scripts. It is therefore not practical to use CPFCMake without CPFBuildscripts. By putting both packages into one, client projects would only need to add one package instead of two.

Currently I am no sure if the simplification is worth the trouble. An alternative could be to turn the python scripts into cmake scripts to get rid of the python dependency. But that would probably decrease the usability.

Advantages:

• The user only needs to add one submodule to the project.
• It feels like they belong together because they can not really be used seperately.
• Currently all tests from CPFTests could then be moved to CPFCMake.

Disadvantages:

• A lot of work.

[Knitschi]

Before we decide if we should do this, we have to see how the copying of the buildscripts is done when the packages are handled by hunter or conan. It may be better then if they are separate packages.

[Knitschi]

I really should think twice if this is necessary. It will be quite some work to join the two.

Pros:

• Clients only need to add one package.
• We could also add the python code from CPFTests to the joined project.
• We could then rename packages to CPFServers and CPFPipeline.

Cons:

• The package gets much bigger.
• We mix python and cmake code in one package.
• Finer granularity might be better.

[Knitschi]

I think it also makes sense to remove the CPFMachines package and put it in another project. The CPFMachines package probably has significantly less reuse potential than the CPFCMake and CPFBuildscript packages. The functionality is fragile and often requires a lot of implementation knowledge to troubleshoot problems.