[PATCH v2] STM32 lwIP addition and CMake support

[Robin Müller]

Hi,

Unfortunately, there was no other reply to the request.

Easiest solution would be to exclude the STM32 code completely out of RTEMS
code for now. I can host it as example code in a personal repository.
But then I might have to change the architecture of the lwIP code again
which provided some building blocks to make porting/using it easier.

Kind Regards
Robin

On Thu, 5 Aug 2021 at 17:00, Gedare Bloom <gedare at rtems.org> wrote:

> STM is not going to fix their Ultimate Liberty License at this time.
>
> https://github.com/STMicroelectronics/STM32CubeH7/issues/139#issuecomment-890806010
>
> So, we need to avoid using their example codes.
>
> On Wed, Jun 9, 2021 at 12:16 PM Gedare Bloom <gedare at rtems.org> wrote:
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210908/cf1c9304/attachment.html>