cmake support about qpc HOT 9 CLOSED

Hi Stefan,
The use of CmakeList.txt has been already demonstrated in the QP/C port to Zephyr.

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

from qpc.

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
Stefan

from qpc.

short explanation of the approach

• the project owner adds qpc as a git submodule to the projects source code tree (e.g. as /Source/qpc
• In the main CMakeLists.txt the engineer adds qpc support simply by setting QPC_CFG variables, adding the qpc subdirectory and adding qpc as library to the application target:

`set(QPC_PROJECT qpc_${PROJECT_NAME}) # the local project name within qpc
set(QPC_CFG_KERNEL ${CONFIG_KERNEL}) # the desired kernel (QV, QK or QXK)
set(QPC_CFG_QSPY ${CONFIG_QSPY}) # add QSPY support? (ON/OFF)
set(QPC_QFG_UNIT_TEST ${CONFIG_UNIT_TEST}) # add unit test support? (ON/OFF)
set(QPC_CFG_GUI ${CONFIG_GUI}) # is it a GUI application (e.g. win32 port) (ON/OFF)

add_subdirectory(qpc)
target_link_libraries(${TGT} PRIVATE 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...

from qpc.

Hi Stefan,
OK, I think that providing CMakeList.txt to the QP/C and QP/C++ could have some merit, so I will look into this.

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

from qpc.

Hi Miro,

thanks for your reply and the valid thoughts expressed therein.
Let me comment on your remarks.

Hi Stefan, OK, I think that providing CMakeList.txt to the QP/C and QP/C++ could have some merit, so I will look into this.

But of course, as with every problem, however complicated, when you look at it the right way, it becomes even more complicated.
Too true :)

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?

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.
The same is true for testing support with QP/Spy. The support for qs is included. But the generation of test cases and the execution of test cases with qspy is subject to application testing and not within the scope of configuring and building a qpc lib for a specific application. Testing support can for sure added with cmake/ctest support. Again, this is for the moment not subject to this project.

And on top of this, the build needs to support various build configurations, such as Debug, Release, and Spy.

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.

And on top of this, the build needs to support several toolchains, GNU-desktop, GNU-ARM, clang-ARM, IAR-ARM, IAR-MSP430, etc. etc.

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.

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.

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
Stefan

from qpc.

Hi Miro,

see the updates in pull request #37

Thanks
Stefan

from qpc.

Hi Miro,

I did it again :)
find another set of updates in the attached tgz file.
The diffs in this archive add cmake support to qpcpp. It also fixes some minor bugs and typos I discovered when porting the cmake support from qpc to qpcpp. For qpcpp the same set of examlples is provided as for qpc.
I discovered that 2 files in the posix-win32-cmake example didn't find their way into your repository:

• dppImages.xml - this is important for the GTK+ example. This is the GTK replacement of the Win32 RC files
• The win32 .rc file in your gui examples uses a utf-16 coding. This is incompatible with the MinGW implementation of windres32. I changed tis to utf-8

Please check the diffs and apply them as you please.

Thanks for your support
Stefan
qpcAll.zip

from qpc.

Done.
Thanks a lot,
--MMS

from qpc.

Thanks Miro :)
Closed because done

from qpc.