[PATCH v2] STM32 lwIP addition and CMake support

[Gedare Bloom]

I joined the Issue. Thanks for working on this.

On Wed, Jun 9, 2021 at 11:30 AM Robin Müller <robin.mueller.m at gmail.com> wrote:
>
> I posted a reply but I think it did not go through. Will post it now.
>
> Kind Regards
> Robin
>
> On Wed, 9 Jun 2021 at 18:31, Robin Müller <robin.mueller.m at gmail.com> wrote:
>>
>> Hi,
>>
>> I received a reply from STM32 about the licensing issues. They requested more specific information about the "vendor device restrictions"  for the HAL code.
>> The issue is here: https://github.com/STMicroelectronics/STM32CubeH7/issues/139
>> Can anyone provide more information about this (maybe even directly in the issue) ? I can forward it to them as well. Thanks a lot in advance!
>>
>> Kind Regards
>> Robin
>>
>> On Wed, 28 Apr 2021 at 02:45, Chris Johns <chrisj at rtems.org> wrote:
>>>
>>> On 28/4/21 2:58 am, Robin Müller 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
>>> For RTEMS what we use has been selected for a range of important reasons and the
>>> rtems-central repo and the qual work highlights the importance of those
>>> decisions. Waf is a python framework for building software and in rtems.git our
>>> build system support is written in a clearly defined portable language with
>>> power helper libraries. We can run code formatters on our build system, have
>>> unit tests and there is even source level debuggers. We treat the build system
>>> like any other piece of code we have.
>>>
>>> > 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.
>>>
>>> What about scons, meson, or a plain Makefile for those who just want to use
>>> make, then there is GNU make and BSD make, the list is large? Do we open the
>>> repo up so all build systems are welcome? I think we would have to so we are not
>>> picking favourites.
>>>
>>> Who tests these build system files when the package is released? As the person
>>> who releases RTEMS I do not have the time or capability to do this.
>>>
>>> > 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.
>>>
>>> I welcome the idea of rtems-cmake to grow a community of those using cmake to
>>> build RTEMS applications. It is great to see this happening.
>>>
>>> > 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 do not have a better solution than PKG config. Most build systems provide
>>> support so it should be something that can be accommodated.
>>>
>>> > 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:
>>>
>>> I would discourage this and maybe not for the reasons you may be thinking of.
>>> The repo is new and is it is exciting there is work happening on it but in time
>>> it will become stable and it will be released with RTEMS and this puts it in the
>>> same configuration management basket as the BSP (kernel) and tools. The RSB can
>>> build it in a controlled way with reports and you just access it like the BSP.
>>>
>>> > 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.
>>>
>>> I see rtems-cmake providing that role, thank you for it. We have learnt the hard
>>> way over a few decades to be mindful when adding these things. Strong portable
>>> eco-system level interfaces are our focus.
>>>
>>> Chris