[PATCH v2] STM32 lwIP addition and CMake support

Robin Müller robin.mueller.m at gmail.com
Tue Apr 27 18:13:00 UTC 2021


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.mueller.m at 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.huber at 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.huber at 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/
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210427/cf41e470/attachment.html>


More information about the devel mailing list