<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">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>