[PATCH v2] STM32 lwIP addition and CMake support

[Chris Johns]

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