Implementing this ticket is not possible if the conan-profile file does not allow defining arbitrary cmake variables. Before I work on this, I have to check that this is possible.
I imagine the following setup:
The file that stores the build-configuration is changed from the xxx.config.cmake file to the conan-profile file. The 1_Configure.py script must be changed to support writing new options into that file via command line.
CPFBuildscript will get the new build-step script 2_GetDependencies.py. The numbers of the following steps need to be incremented accordingly. I should also consider dropping the numbers completely. The GetDependencies.py script will then run the conan install step which downloads or builds the dependencies and creates the conanbuildinfo.cmake file in the build-tree. This file is used to inject the configuration into the CMake generate step.
Problems:
Can the cmake generator be added to the conan-profile and use?
What happens to the cmake toolchain files? I think they are required for cross building.
This change will add a strong dependency to the conan package manager. It could be later be removed by extending the functionality behind the 2_GetDependencies.py to support other package managers.
Can this mechanism be extended to allow the quich switch between conan-packages and git-submodules?
Implementing this ticket is not possible if the conan-profile file does not allow defining arbitrary cmake variables. Before I work on this, I have to check that this is possible.
I imagine the following setup:
2_GetDependencies.py. The numbers of the following steps need to be incremented accordingly. I should also consider dropping the numbers completely. TheGetDependencies.pyscript will then run the conan install step which downloads or builds the dependencies and creates the conanbuildinfo.cmake file in the build-tree. This file is used to inject the configuration into the CMake generate step.Problems:
2_GetDependencies.pyto support other package managers.