[PATCH v2] STM32 lwIP addition and CMake support

[Robin Müller]

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210609/e6eadab6/attachment.html>