Almost all files in the Cube repository have the new BSD3 license, but some application and example files still appear to be licensed under SLA0044. I created an issue in the STM32H7 Cube repository ( https://github.com/STMicroelectronics/STM32CubeH7/issues/139) , and the Cube developers seem to track the issue list quite regularly. Hopefully there will be an answer soon..
Kind Regards Robin On Tue, 27 Apr 2021 at 18:58, Robin Müller <robin.muelle...@gmail.com> 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. > > 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. > 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. > 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 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: > 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. > > Kind Regards > Robin > > On Tue, 27 Apr 2021 at 18:27, Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> On 27/04/2021 17:23, Gedare Bloom wrote: >> >> >> I can try to get a better license for the files taken from the >> example. If that doesn't work out, I guess some scripting will be >> necessary. The problem is that these files were modified >> >> to be usable for RTEMS.. >> >> >> > Thanks. It might require iterating with the vendor. From past >> > experience, that can take months or years, or never happen. I think we >> > are generally interested in supporting the option for users to build >> > such proprietary drivers. After all, a user might be creating their >> > own drivers too. So, from a technical perspective, how we manage that >> > integration is a welcome discussion. We just need to be careful that >> > we don't try to integrate it at the source code level. I hope that >> > makes sense. >> >> STMicroelectronics fixed their license at some point. The newer code has >> this license: >> >> https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/include/stm32h7xx.h >> >> Maybe you can import the code from a more recent distribution. >> >> -- >> embedded brains GmbH >> Herr Sebastian HUBER >> Dornierstr. 4 >> 82178 Puchheim >> Germany >> email: sebastian.hu...@embedded-brains.de >> phone: +49-89-18 94 741 - 16 >> fax: +49-89-18 94 741 - 08 >> >> Registergericht: Amtsgericht München >> Registernummer: HRB 157899 >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler >> Unsere Datenschutzerklärung finden Sie hier: >> https://embedded-brains.de/datenschutzerklaerung/ >> >>
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
