[PATCH v2] STM32 lwIP addition and CMake support

[Robin Müller]

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/dbeffe5f/attachment.html>