-
Notifications
You must be signed in to change notification settings - Fork 244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmake support #35
Comments
Hi Stefan, But the general policy of QP is to impose as little as possible on the application developers. In particular, NO particular software build process is dictated because the development teams tend to use their own build process anyway. Consequently, the standard examples shipped with QP intentionally contain only minimal Makefiles (or minimal projects for specific tools, such as KEIL-MDK, IAR-EWARM, TI-CCS, etc.) Also, instead of imposing a build process, a recent focus was on standard packaging of QP software and making it more widely accessible. To this end, QP/C and QP/C++ are now available as CMSIS-packs, plese see the cmsis-packs repo. I hope that my comments make sense to you. --MMS |
Hi Miro, one of the main differences between CMake and other build systems is, that CMakeLists in the end are an integral part of the source code tree. The Makefiles (or other build files) generated by CMake then may (or even should) reside outside the source code tree, as it's also shown in the qpc examples. I enhanced qpc locally with CMakeLists that support a flexible adaptation to the project. The desired port, kernel and build specialities are automagically set by evaluating existing CMake variables or generation time options. Other than the port to Zephyr you mentioned above, my approach is not a special port, which in itself resides outside the qpc port system. This approach is fully integrated into qpc and allows to build a qpc project with any supported port for the target systems. At that time it is still not 100% complete, as I lack some information, which is not provided in the CMake docs. As an example, the support for some less popular cross compilers is not available to me, as I don't have any information, which values would be given by the variables CMAKE_C_COMPILER or CMAKE_C_COMPILER_ID. If my adaptation however could be an approach interesting to not only me, I had no problem creating a pull request out of it. Thanks for your consideration |
short explanation of the approach
`set(QPC_PROJECT qpc_${PROJECT_NAME}) # the local project name within qpc add_subdirectory(qpc) compiler settings, options and so on can the be added globally or more specific on the "qpc" target. All settings given by the toolchain selected for the project will of course be respected by the qpc compilation as well. that's it... |
Hi Stefan, But of course, as with every problem, however complicated, when you look at it the right way, it becomes even more complicated. So it is with cmake support. If it was to be general, it should include not just the built-in kernels (QV, QK, QXK), but also all supported 3rd-party RTOSes and General Purpose OSes (POSIX, POSIX-QV, Win32, Win32-QV). And how about supporting testing with QP/Spy? And on top of this, the build needs to support various build configurations, such as Debug, Release, and Spy. And on top of this, the build needs to support several toolchains, GNU-desktop, GNU-ARM, clang-ARM, IAR-ARM, IAR-MSP430, etc. etc. So, in the end, I think that truly generic CmakeList.txt would be too complex to be useful. But perhaps some limited scope (say, only built-in kernels and only ARM Cortex-M) could be workable. --MMS |
Hi Miro, thanks for your reply and the valid thoughts expressed therein.
My approach's target is to be able to integrate qpc into a larger scale application. For this basically only the qpc directories 'src', 'ports' and 'include' are necessary. So my qpc support is limited to the - let's call it - qpc core. I don't look into examples (or no more, than absolutely necessary) or into 3rd-party code. Everything under ports (with the only exception of 'lint-plus') is supported for cmake use. I can also demonstrate the approach with may playground project, a small traffic light simulation. This can be configured and built from one CMakeListsfile to build and run on win32 (incl. win32-qv), posix (Linux, also with posix-qv) and arm-cr targets. The support for RT-Oses like uc-os2 or freertos is, as already said, limited to the qpc port only. The integration of the freertos source tree or uc-os2 into a cmake based build system is application specific and therefore out of my scope.
As long as Debug or Release configurations switch between different sets of compiler/linker options and respective defines, this a built-in feature of cmake. It needs to be set up correctly in the 'toolchain' file used to define the (cross) compilation environment.
This request is already included in my approach. Cmake delivers the toolchain id (gnu, clang, iar, ...) in global Cmake variables. I cannot test all variants due to the lack of available toolchains in my environment. I think with some support of an interested community, this project may also grow for the sake of qpc.
I think, you are right! I also think, that many of the points you mentioned above are either already built-in into cmake itself, or addressed by the cmake support from my small project. Additionally, I am convinced, that with the support of the interested community, this system can be improved and optimized even further. A last word to qpcpp. As of today, I only focused on qpc. I'm sure, that the ideas can also work as a blueprint for qpcpp. Thanks for reading |
Hi Miro, see the updates in pull request #37 Thanks |
Hi Miro, I did it again :)
Please check the diffs and apply them as you please. Thanks for your support |
Done. |
Thanks Miro :) |
Hi Miro,
are there any plans to provide qpc with cmake support (CMakeLists.txt files)?
Thanks
Stefan
The text was updated successfully, but these errors were encountered: