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
