<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi, Robin,<div class=""><br class=""></div><div class="">Would it be possible to retain the STM32 code, but carve out the “contaminated” lwIP code into a patch file. Then RTEMS code base remains “clean” and if I, any user, chose to enable lwIP on STM32, I could do so by applying that patch. I’d contaminate my src tree, but that’d be my responsibility and in any case, I’d be compliant (target is after all an STM32…).</div><div class=""><br class=""></div><div class="">The “patch trick” to manage license contamination has worked well for others in the past.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">-Shiro<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 8, 2021, at 11:51 AM, Robin Müller <<a href="mailto:robin.mueller.m@gmail.com" class="">robin.mueller.m@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hi,</div><div class=""><br class=""></div><div class="">Unfortunately, there was no other reply to the request.</div><div class=""><br class=""></div><div class="">Easiest solution would be to exclude the STM32 code completely out of RTEMS code for now. I can host it as example code in a personal repository.</div><div class="">But then I might have to change the architecture of the lwIP code again which provided some building blocks to make porting/using it easier.</div><div class=""><br class=""></div><div class="">Kind Regards<br class=""></div><div class="">Robin<br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 5 Aug 2021 at 17:00, Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank" class="">gedare@rtems.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">STM is not going to fix their Ultimate Liberty License at this time.<br class="">
<a href="https://github.com/STMicroelectronics/STM32CubeH7/issues/139#issuecomment-890806010" rel="noreferrer" target="_blank" class="">https://github.com/STMicroelectronics/STM32CubeH7/issues/139#issuecomment-890806010</a><br class="">
<br class="">
So, we need to avoid using their example codes.<br class="">
<br class="">
On Wed, Jun 9, 2021 at 12:16 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank" class="">gedare@rtems.org</a>> wrote:<br class="">
><br class="">
> I joined the Issue. Thanks for working on this.<br class="">
><br class="">
> On Wed, Jun 9, 2021 at 11:30 AM Robin Müller <<a href="mailto:robin.mueller.m@gmail.com" target="_blank" class="">robin.mueller.m@gmail.com</a>> wrote:<br class="">
> ><br class="">
> > I posted a reply but I think it did not go through. Will post it now.<br class="">
> ><br class="">
> > Kind Regards<br class="">
> > Robin<br class="">
> ><br class="">
> > On Wed, 9 Jun 2021 at 18:31, Robin Müller <<a href="mailto:robin.mueller.m@gmail.com" target="_blank" class="">robin.mueller.m@gmail.com</a>> wrote:<br class="">
> >><br class="">
> >> Hi,<br class="">
> >><br class="">
> >> 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 class="">
> >> The issue is here: <a href="https://github.com/STMicroelectronics/STM32CubeH7/issues/139" rel="noreferrer" target="_blank" class="">https://github.com/STMicroelectronics/STM32CubeH7/issues/139</a><br class="">
> >> 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!<br class="">
> >><br class="">
> >> Kind Regards<br class="">
> >> Robin<br class="">
> >><br class="">
> >> On Wed, 28 Apr 2021 at 02:45, Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank" class="">chrisj@rtems.org</a>> wrote:<br class="">
> >>><br class="">
> >>> On 28/4/21 2:58 am, Robin Müller wrote:<br class="">
> >>> > Okay, I can understand that you'd like to have one build system only. We had the<br class="">
> >>> > same issue with a former Makefile build system and the new CMake system and<br class="">
> >>> > decided to make the former system obsolete> because maintaining both of them would be too much work<br class="">
> >>> For RTEMS what we use has been selected for a range of important reasons and the<br class="">
> >>> rtems-central repo and the qual work highlights the importance of those<br class="">
> >>> decisions. Waf is a python framework for building software and in rtems.git our<br class="">
> >>> build system support is written in a clearly defined portable language with<br class="">
> >>> power helper libraries. We can run code formatters on our build system, have<br class="">
> >>> unit tests and there is even source level debuggers. We treat the build system<br class="">
> >>> like any other piece of code we have.<br class="">
> >>><br class="">
> >>> > First thing I can do is that I split up the patch and extract the CMake<br class="">
> >>> > specific files. Concerning a clean solution to allow users to use CMake without<br class="">
> >>> > introducing files like CMakeLists.txt,<br class="">
> >>> > I am not sure right now. Extracting the information required by CMake would<br class="">
> >>> > again require scripts to export source files and include paths.<br class="">
> >>> > The simplest solution would still be a CMakeLists.txt file in the root here<br class="">
> >>> > which simply sets source files and include paths in the parent scope.<br class="">
> >>> > which would again be another form of maintenance burden because it still needs<br class="">
> >>> > to figure out which port sources to add etc.<br class="">
> >>><br class="">
> >>> What about scons, meson, or a plain Makefile for those who just want to use<br class="">
> >>> make, then there is GNU make and BSD make, the list is large? Do we open the<br class="">
> >>> repo up so all build systems are welcome? I think we would have to so we are not<br class="">
> >>> picking favourites.<br class="">
> >>><br class="">
> >>> Who tests these build system files when the package is released? As the person<br class="">
> >>> who releases RTEMS I do not have the time or capability to do this.<br class="">
> >>><br class="">
> >>> > The rtems-cmake support is able to live without CMakeLists.txt files in RTEMS<br class="">
> >>> > because the BSP is already compiled at that point. Doing something similar<br class="">
> >>> > would require a similar process like done in the BSP where rtems-lwip is<br class="">
> >>> > compiled as a static library for a specific BSP,<br class="">
> >>> > installed somewhere and then an application can link against it while also<br class="">
> >>> > including the headers.<br class="">
> >>><br class="">
> >>> I welcome the idea of rtems-cmake to grow a community of those using cmake to<br class="">
> >>> build RTEMS applications. It is great to see this happening.<br class="">
> >>><br class="">
> >>> > For the RTEMS BSP this is done through provided PKG Config files. It just seems<br class="">
> >>> > like a lot of effort for a comparatively small library.<br class="">
> >>> > Maybe someone has a better idea?<br class="">
> >>><br class="">
> >>> I do not have a better solution than PKG config. Most build systems provide<br class="">
> >>> support so it should be something that can be accommodated.<br class="">
> >>><br class="">
> >>> > I am also not sure if users who are used to CMake would not just do the same<br class="">
> >>> > thing I did if there are no CMakeLists.txt files present and the<br class="">
> >>> > library/repository is simple enough:<br class="">
> >>><br class="">
> >>> I would discourage this and maybe not for the reasons you may be thinking of.<br class="">
> >>> The repo is new and is it is exciting there is work happening on it but in time<br class="">
> >>> it will become stable and it will be released with RTEMS and this puts it in the<br class="">
> >>> same configuration management basket as the BSP (kernel) and tools. The RSB can<br class="">
> >>> build it in a controlled way with reports and you just access it like the BSP.<br class="">
> >>><br class="">
> >>> > Add those themselves in the project root or throughout the repository fork<br class="">
> >>> > structure. But it's your call of course. Maybe some more (user) opinions would<br class="">
> >>> > help as well.<br class="">
> >>><br class="">
> >>> I see rtems-cmake providing that role, thank you for it. We have learnt the hard<br class="">
> >>> way over a few decades to be mindful when adding these things. Strong portable<br class="">
> >>> eco-system level interfaces are our focus.<br class="">
> >>><br class="">
> >>> Chris<br class="">
</blockquote></div>
_______________________________________________<br class="">devel mailing list<br class=""><a href="mailto:devel@rtems.org" class="">devel@rtems.org</a><br class="">http://lists.rtems.org/mailman/listinfo/devel</div></blockquote></div><br class=""></div></body></html>