[PATCH v2] STM32 lwIP addition and CMake support

[Gedare Bloom]

On Tue, Apr 27, 2021 at 10:58 AM 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 think this way of building/installing the network stack before you
link to the application is the right way to go, and providing a
consistent interface like pkgconfig would be the best approach to
avoid entangling user applications with the RTEMS side.

We find that when user applications peek under the hood of the build
system, they can easily create dependencies on what should be rightly
internal implementation decisions within RTEMS. Then, we change how
our build works, and their build breaks in bad, sometimes
random-seeming ways. (Usually, I have seen this manifest when someone
plucks variables out of the build system and drops them in an
environment variable for their build.) By defining the pkgconfig or
similar approach to export information about the built network stack,
we can better support multiple stacks and maintain them with a
consistent guidance how to interface application build systems with
the RTEMS side of things.

> 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.
>
There are many build systems out there. I'm not interested in
accommodating everyone's personal favorite within the RTEMS
repositories. I'm happy to allow/support them to use whatever build
system they want for their application. Admittedly, the learning curve
for waf can be quite high, but the power, flexibility, and performance
we get out of it is what led us to adopt it over alternatives,
including cmake. We're happy to provide assistance and to know where
more documentation is needed for contributed ports and drivers.

For some historical context...
https://lists.rtems.org/pipermail/devel/2015-September/012626.html
https://lists.rtems.org/pipermail/devel/2016-July/043530.html

Gedare

> 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/
>>