<div dir="ltr"><div>I posted a reply but I think it did not go through. Will post it now.</div><div><br></div><div>Kind Regards</div><div>Robin<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 9 Jun 2021 at 18:31, Robin Müller <<a href="mailto:robin.mueller.m@gmail.com">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>I received a reply from STM32 about the licensing issues. They requested more specific information about the "vendor device restrictions"  for the HAL code.<br>The issue is here: <a href="https://github.com/STMicroelectronics/STM32CubeH7/issues/139" target="_blank">https://github.com/STMicroelectronics/STM32CubeH7/issues/139</a></div><div>Can anyone provide more information about this (maybe even directly in the issue) ? I can forward it to them as well. Thanks a lot in advance!</div><div><br></div><div>Kind Regards</div><div>Robin<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 28 Apr 2021 at 02:45, 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 28/4/21 2:58 am, Robin Müller wrote:<br>
> Okay, I can understand that you'd like to have one build system only. We had the<br>
> same issue with a former Makefile build system and the new CMake system and<br>
> decided to make the former system obsolete> because maintaining both of them would be too much work<br>
For RTEMS what we use has been selected for a range of important reasons and the<br>
rtems-central repo and the qual work highlights the importance of those<br>
decisions. Waf is a python framework for building software and in rtems.git our<br>
build system support is written in a clearly defined portable language with<br>
power helper libraries. We can run code formatters on our build system, have<br>
unit tests and there is even source level debuggers. We treat the build system<br>
like any other piece of code we have.<br>
<br>
> First thing I  can do is that I split up the patch and extract the CMake<br>
> specific files. Concerning a clean solution to allow users to use CMake without<br>
> introducing files like CMakeLists.txt,<br>
> I am not sure right now. Extracting the information required by CMake would<br>
> again require scripts to export source files and include paths.<br>
> The simplest solution would still be a CMakeLists.txt file in the root here<br>
> which simply sets source files and include paths in the parent scope.<br>
> which would again be another form of maintenance burden because it still needs<br>
> to figure out which port sources to add etc.<br>
<br>
What about scons, meson, or a plain Makefile for those who just want to use<br>
make, then there is GNU make and BSD make, the list is large? Do we open the<br>
repo up so all build systems are welcome? I think we would have to so we are not<br>
picking favourites.<br>
<br>
Who tests these build system files when the package is released? As the person<br>
who releases RTEMS I do not have the time or capability to do this.<br>
<br>
> The rtems-cmake support is able to live without CMakeLists.txt files in RTEMS<br>
> because the BSP is already compiled at that point. Doing something similar<br>
> would require a similar process like done in the BSP where rtems-lwip is<br>
> compiled as a static library for a specific BSP,<br>
> installed somewhere and then an application can link against it while also<br>
> including the headers.<br>
<br>
I welcome the idea of rtems-cmake to grow a community of those using cmake to<br>
build RTEMS applications. It is great to see this happening.<br>
<br>
> For the RTEMS BSP this is done through provided PKG Config files. It just seems<br>
> like a lot of effort for a comparatively small library.<br>
> Maybe someone has a better idea?<br>
<br>
I do not have a better solution than PKG config. Most build systems provide<br>
support so it should be something that can be accommodated.<br>
<br>
> I am also not sure if users who are used to CMake would not just do the same<br>
> thing I did if there are no CMakeLists.txt files present and the<br>
> library/repository is simple enough:<br>
<br>
I would discourage this and maybe not for the reasons you may be thinking of.<br>
The repo is new and is it is exciting there is work happening on it but in time<br>
it will become stable and it will be released with RTEMS and this puts it in the<br>
same configuration management basket as the BSP (kernel) and tools. The RSB can<br>
build it in a controlled way with reports and you just access it like the BSP.<br>
<br>
> Add those themselves in the project root or throughout the repository fork<br>
> structure. But it's your call of course. Maybe some more (user) opinions would<br>
> help as well.<br>
<br>
I see rtems-cmake providing that role, thank you for it. We have learnt the hard<br>
way over a few decades to be mindful when adding these things. Strong portable<br>
eco-system level interfaces are our focus.<br>
<br>
Chris<br>
</blockquote></div>
</blockquote></div>