Open stefanct opened 8 months ago
Hi @stefanct, thanks for all recent feedback to our experimental version of kconfig+cmake design, this is very valuable to us! The development team is working on re-design of kconfig+cmake for our SDK, they will take your suggestions and try to meet the requirement in the design.
I tried to build multiple binaries (for RT1020 and RT1024) on the command line using the SDK's cmake in a shared build directory. To that end, I include
core/cmake/mcux.cmake
once per project after configuration (e.g., callingadd_executable()
) in the respective CMakeLists.txt files of the projects. Unlike the SDK examples I would like to be able to process the whole directory tree of projects with cmake in a single run.There are some minor(?) changes required in the SDK to do this successfully:
cmake/kconfig.cmake
require to have unique names across projects (instead of all projects having a singlemenuconfig
etc). I have simply prefixed them with${PROJECT_NAME}_
(e.g., instead ofmake menuconfig
one has to callmake hello_menuconfig
).set_CMSIS.cmake
the include guard needs to be changed toDIRECTORY
scope. The current global scope prohibits configuration of cmsis for all but the very first project. I did not notice any ill effects from this. Is there a rationale for the global guard?Neither of these changes breaks the functionality when using cmake in single projects as before AFAICT. However, of course the command names change, which might surprise users and requires some documentation changes, if implemented. In large deployments like the SDK's example repository the approach with single, separated projects is probably way more desirable but it's a restriction that is not necessary and complicates some setups, e.g., where libraries are built and used in the same cmake tree.