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> wrote: > STM is not going to fix their Ultimate Liberty License at this time. > > 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> 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> > 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> > 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 > > >> 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> 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
