Closed Jman420 closed 7 months ago
I was thinking about this more and I'm beginning to think that the CPU Detection is really best used at compilation time for KFR, but in the Consuming Project having a pre-populated cmake file with a definition for the CPU_ARCH which that KFR Library was compiled with will be even better.
The pre-populated cmake file would contain a set() for CPU_ARCH and the definition for target_set_arch(). The consuming project would then only need to use the target_set_arch() function to set the compiler flags on the appropriate builds.
I definitely like this 'kfr_include.cmake' approach much better.
In KFR6 build system and CMake configuration have been fully refactored.
The recommended method now is to build kfr in a separate step and use find_packege(KFR CONFIG)
I moved all of the CPU & Architecture Detection CMake code into a dedicated cmake file and added the cmake folder as an install directory so that consuming Projects can use all that detection logic in their CMake in order to set the appropriate preprocessor definitions.
I've included snippets from my Project's CMakeList to provide some guidance. I've also implemented this method of using KFR in my Project as an example here : https://github.com/Jman420/menrva/blob/feature/test-harness/engine/src/CMakeLists.txt#L71