cmake support for qpc

[stefanschober]

This pull request adds cmake support to qpc as described in issue #35

[quantum-leaps]

Hi Stefan, Thanks a lot for this extensive work and all these CMakeList.txt files. I need to take a closer look and check/test how this works.

Also, one general comment regarding the pull requests is that they cannot be merged directly into QP/C (or QP/C++) projects. This is because this complicates the clean provenance of the QP/C (or QP/C++) software and might interfere with the dual-licensing model. (Other GitHub projects from QuantumLeaps are licensed differently and don't have these restrictions.)

[stefanschober]

Thanks Miro :)

to see how this works, I added cmake support to '/examples/posix-win32/dpp' and to '/examples/qwin-gui/dpp-gui'.

The first one can be configured with 'cmake -B .' and then build it with 'cmake --build '. This should work without problems on Linux and Windows systems by building qpc from the correct port. For the second one, configure with 'cmake -B -DQPC_CFG_GUI=ON .' and build like above. This obviously only works for MS-Windows. My own playground projects (e.g. the trafficlight mentioned earlier) also support QPC_CFG_GUI under Linux with a board support package that uses GTK3.

The system also works with cross compilation toolchains by providing the appropriate toolchain description to cmake. This is not included. Cmake toolchain files can be easily found on the internet. For mingw-gcc (to cross compile win32 applications on a Linux machine) or for arm-none-eabi-gcc, I can also provide examples, if you give me a hint, where to place those (e.g. /3rd-party/cmake/toolchains).

Best regards Stefan

[stefanschober]

Hi Miro,

I meanwhile completed the cmake support in qpc. To illustrate how all fits together, I provided a new example in ".../examples/posix-win32-gui_cmake/dpp".

This example works out of the box under Linux or on a Windows machine in a MSY2/MinGW environment. It features support for all qpc ports, including win32 (-qv) and posix (-qv) and also for the RTOS ports. The RTOSes itself need cmake support, where not available. Also the qpc configurations Debug, Release Spy as well as qutest setups can be configured and built. Call 'cmake .' to see a short introductory explanation together with an error message :) Use 'cmake -B Build .' or 'cmake --preset=dpp' for a successfull generation of the build system. After that you may build with 'cmake --build Build' or, should you prefer the defined presets 'cmake --build --preset=dpp'. To see the predefined presets call 'cmake --preset=x'

[quantum-leaps]

Hi Stefan, Thank you again for the work on cmake for QP. As I tried to explain before, pull requests cannot be directly accepted into the qpc or qpcpp repositories because of the dual licensing restrictions. However, I am contemplating changing the repository structure and leaving only the QP source code inside. The examples and 3rd-party code could then be placed into some other repos, which could be open to public contributions. These other repos could sub-module the simplified qpc or qpcpp repos. I'm still not quite sure about the implications of such a restructuring, so please give me some time. --MMS

[quantum-leaps]

Hi Stefan,

I can see that you've done quite a bit of work on Cmake support for QP/C. I'm not sure if you noticed that a few days ago, the qpc repo on GitHub has been restructured:

https://github.com/QuantumLeaps/qpc

Specifically, the examples directory is now a submodule:

https://github.com/QuantumLeaps/qpc-examples

One of the motivations for this restructuring was to enable community contributions to the examples sub-repo. Would it be possible to contribute an example for the Cmake? I know that you describe how to build such an example, but having at least one working "out of the box" would be helpful to get started.

I understand that some Cmake stuff needs to go to the qpc source code, and I'll merge it separately. Here I have one question/doubt. The CmakeList.txt file in the qpc/src/qf/ subdirectory contains the file qf_actq.c. But this file must be EXCLUDED in all ports to 3rd-party RTOSes (embOS, FreeRTOS, uC/OS-II, ThreadX, Zephyr). I'm not sure if these ports would work correctly.

Thanks again for the work and please think of contributing an example.

Best regards, Miro

[stefanschober]

Hi Miro,

thanks for your comments. Yes, I recognized the restructured qpc repo and updated my fork accordingly. It now also reflects the submodule status of examples.

My latest commit to the branch cmakeSupport in my pull request to qpc respects your remark concerning the status of qf/qf_actq.c, which should not be part of the build for all RTOS related ports. This is included.

I also added a pull request to the repo of qpc-examples which includes the cmake additions I did to already existing examples and it also includes a full featured example in the directory posix-win32-cmake. In addition I made my own Trafficlight project publicly visible and added a link to this project in the Readme.mdfile.

[stefanschober]

The latest commit 5f676d7 also excludes qf_mem.c if the port is for uc-os2.

[stefanschober]

Hi Miro,

I synced my fork with the latest upstream changes from your repositories and was able to re-produce the failed build due to the lack of QP_CONFIG. I introduced another configuration variable (QPC_CFG_USE_QP_CONFIG), which when not pre-defined via environment or master CMakeFiles.txt will be set to OFF automatically. When set it adds the CMAKE_SOURCE_DIR to the list of include dirs in order to properly find the file qp_config.h in the main directory. In the ports section, it also adds ports/config to the list of include dirs. Is this suitable? You find the updated example in examples\posix-win32-cmake/dpp, which sets the configuration variable via updated presets dpp and mingw. They now build in my configuration out of the box.

[stefanschober]

closed by merging into master branch