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.muelle...@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 <chr...@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 >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
