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