<div dir="ltr"><div>I added the suggestions by Chris Johns now and performed some more tests (for example disabling the default compiler checks, custom checks are required for RTEMS).<br><br>I used RTEMS_PREFIX instead of PREFIX because PREFIX appears to be a reserved name in CMake, and RTEMS_PREFIX is also a little bit more explicit.<br></div><div>It is now possible to set a separate BSP path by supplying RTEMS_PATH and a different tools path by supplying RTEMS_TOOLS like suggested.</div><div><br></div><div>Maybe CMake can also read the .pc pkgfiles in some way to determine compiler/linker flags automatically, at least Kitware has a module like</div><div>this <a href="https://github.com/Kitware/CMake/blob/master/Modules/FindPkgConfig.cmake">https://github.com/Kitware/CMake/blob/master/Modules/FindPkgConfig.cmake</a> . <br></div><div><br></div><div>Kind Regards<br></div><div>Robin<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 11 Dec 2020 at 11:14, Robin Müller <<a href="mailto:robin.mueller.m@gmail.com" target="_blank">robin.mueller.m@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>There seems to be positive feedback, thanks for that.</div><div><br></div><div>I can adapt the naming to be more consistent with your system.</div><div>My system is currently assuming that the RTEMS tools and the BSP are both located at RTEMS_INST<br></div><div>I guess the first command:<br><br>cmake -DPREFIX=/install-point -DRTEMS_BSP=arm/stm32h7<br><br></div><div>Would have the purpose to install the BSP itself? Right now, I also used the tools path to autodetermine the RTEMS version</div><div>if the version is not supplied manually.cmake by extracting the last number in the supplied RTEMS_INST path.</div><div><br></div><div>I have not really thought about the install process yet, I simply built the binary in a separate folder out of source like normally done in CMake.</div><div>But this should generally be possible, CMake has an install command as well and the install location can be set using CMAKE_INSTALL_PREFIX<br><br></div><div>Is it possible to get the pkgconfig files without building the BSPs? That would be good so more hardware configurations can be added without having to build every BSP.</div><div><br></div><div>Kind Regards <br></div><div>Robin<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 11 Dec 2020 at 10:59, Stanislav Pankevich <<a href="mailto:s.pankevich@gmail.com" target="_blank">s.pankevich@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi all,</div><div><br></div><div>> I was wondering whether <span>CMake</span> support or an 
example is available or will be added in the future. We are using a 
framework which has different abstraction layers for OSes like 
(embedded) Linux, RTEMS and FreeRTOS, but we would like to use the same 
build system to build applications and right now <span>CMake</span> is our favourite because other tools like the Catch2 test framework are also built with <span>CMake</span> and there is a lot more documentation available for <span>CMake</span>.</div><div><br></div><div>I would like to share our (PTS GmbH, Berlin) experience of using CMake with RTEMS. Our case is similar to that of Robin Müller's and our own software is all CMake-based. An additional advantage for using CMake for us is that the NASA cFS framework has recently switched to CMake so it is much easier to integrate it into the existing CMake tree. Another integration exercise that we had done before was to build RTEMS and DLR Outpost with CMake and that was also quite straightforward in spite of the fact the DLR Outpost didn't have a CMake layer.<br></div><div><br></div><div>~1 year ago we have captured all the RTEMS compilation and linking commands done by Autoconf for building the ARM-based BSP and converted them into CMakeLists.txt files. At that time, we didn't know how exactly the existing build system worked, so we were very careful and created many CMakeLists files, one for a folder (example: cpukit/libmisc/cpuuse or our own BSP folder). Our setup in the end is not 3 files but 60 files but the idea is the same: configs are collected in a few files, the rest are simply assigning source files to object/library targets. No changes are made to RTEMS source or build files. Instead, we keep all CMake scripts in a separate folder called: rtems-cmake-integration.<br></div><div><br></div><div>One of the problems we see with this approach is updating to newer versions of RTEMS. If the CMake files do not co-exist with the RTEMS development tree, then it might be a manual exercise every time to make sure that the CMake integration layer always reflects what the developers of RTEMS intend it to be. Having this said, our 1-year-old CMake setup has been very stable so far, so we might as well stick with it for the time being.</div><div><br></div><div>Having this said, I would like to avoid pushing the CMake-way of doing things as a better way. Instead, I could contribute feedback to Robin's work here: <a href="https://github.com/rmspacefish/rtems-cmake" target="_blank">https://github.com/rmspacefish/rtems-cmake</a>. For example, I could do the exercise of using his Just 3 files to see if our embedded target would compile and run. No hard promises about the time frames though until the Christmas holidays :)<br></div><div><br></div><div>Thank you for your attention.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 11, 2020 at 1:15 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 10, 2020 at 5:58 PM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11/12/20 8:51 am, Robin Müller wrote:<br>
> Hello,<br>
> <br>
> I created a repository on github for the first version of what a CMake support<br>
> for RTEMS might look like:<br>
> <br>
> <a href="https://github.com/rmspacefish/rtems-cmake" rel="noreferrer" target="_blank">https://github.com/rmspacefish/rtems-cmake</a><br>
> <<a href="https://github.com/rmspacefish/rtems-cmake" rel="noreferrer" target="_blank">https://github.com/rmspacefish/rtems-cmake</a>><br>
> <br>
<br>
Awesome and thanks. :)<br></blockquote><div><br></div><div>Agreed. Bear with us being picky. We want things to be as</div><div>consistent as possible across BSPs, architectures, RTEMS versions,</div><div>and (hopefully) build systems. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> I tried to extract generic components like determining library paths into<br>
> functions  (RTEMSGeneric.cmake)<br>
> and there is a hardware specific file where flags for specific<br>
> BSPs/Architectures can be set (RTEMSHardware.cmake).<br>
> <br>
> I was able to compile both the hello project and my STM32 blinky project with<br>
> really similar and short CMake files which simply call rtems_general_config.<br>
> with a simple command like<br>
> <br>
> cmake -DRTEMS_INST=$RTEMS_INST -DRTEMS_BSP=arm/stm32h7<br>
<br>
Would it be possible to align the naming to be consistent with the names we<br>
currently have? We use --rtems-tools for the path to the tools so would<br>
RTEMS_TOOLS work?<br>
<br>
We also provide the ability to specify where RTEMS (the RTEMS BSP) is installed.<br>
In some configurations we have a prefix, where the application or library being<br>
built are installed plus the RTEMS tools path and the RTEMS BSP path. They can<br>
all be the same or different.<br>
<br>
I am not sure what cmake does for the prefix so I will use PREFIX in my examples:<br>
<br>
 cmake -DPREFIX=/install-point -DRTEMS_BSP=arm/stm32h7<br>
<br>
Internally RTEMS_TOOLS and RTEMS would be set to PREFIX.<br>
<br>
 cmake -DPREFIX=/install-point -DRTEMS_TOOLS=/tools-path -DRTEMS_BSP=arm/stm32h7<br>
<br>
RTEMS_TOOLS is defined and RTEMS is set to RTEMS_TOOLS.<br>
<br>
Finally we can have:<br>
<br>
 cmake -DPREFIX=/install-path \<br>
       -DRTEMS_TOOLS=/tools-path<br>
       -DRTEMS=/bsp-path \<br>
       -DRTEMS_BSP=arm/stm32h7<br>
<br>
All are left as defined on the command line.<br>
<br>
We have this separation so you can build a set of tools and build different<br>
branches of RTEMS and then different branches of the application or library for<br>
any of those combinations. A typical user will use the first or second option<br>
and if testing new releases or versions you can separate out the various paths.<br>
Separating the paths lets you some parts without having to build all the parts.<br>
<br>
> or<br>
> <br>
> cmake -DRTEMS_INST=$RTEMS_INST -DRTEMS_BSP=sparc/erc32<br>
> <br>
> and then cmake --build .<br>
> <br>
> I made a test repository containing everything :<br>
> <a href="https://github.com/rmspacefish/rtems-demo" rel="noreferrer" target="_blank">https://github.com/rmspacefish/rtems-demo</a><br>
> <<a href="https://github.com/rmspacefish/rtems-demo" rel="noreferrer" target="_blank">https://github.com/rmspacefish/rtems-demo</a>><br>
> <br>
> Maybe this could be a part of the RTEMS repositories? <br>
<br>
This could be possible. It will come down to people using the package and the<br>
demand. The rtems_waf package is a top level RTEMS repo because it is used in<br>
libbsd and examples.<br>
<br>
The rtems-examples repo maybe be a good place to look at adding support and<br>
making it visible to the wider RTEMS community. I am not sure if this would be a<br>
submodule to github or not. I would love to hear what others think.<br></blockquote><div><br></div><div>If it is just an example, I'd prefer not to have another git repo. But if it turns out</div><div>to work like the waf where you can close the rtems_cmake repo as a submodule,</div><div>execute a couple of commands, and poof you can build an application, I'd be ok</div><div>with it being a repo. I hope that makes sense -- example vs reusable </div><div>infrastructure.</div><div><br></div><div>Thinking long term, when we have examples, not infrastructure, </div><div>rtems-examples could have a build_systems subdirectory and</div><div>then cmake, meson, scons, etc. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> In any case, I think it<br>
> can help people who would like to build their application<br>
> with CMake. The hello world example for CMake would be similar to building the<br>
> waf example for the sparc/erc32, with the difference that the<br>
> CMake support would have to be cloned and the build commands are a little bit<br>
> different.<br>
<br>
This is a really great start and I thank you for it. We are open to supporting<br>
all build systems. It is about individuals providing the support and then being<br>
thee to maintain it over a period of time.<br></blockquote><div><br></div><div>+1</div><div><br></div><div>--joel </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Chris<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div>
</blockquote></div>