I added the suggestions by Chris Johns now and performed some more tests (for example disabling the default compiler checks, custom checks are required for RTEMS).
I used RTEMS_PREFIX instead of PREFIX because PREFIX appears to be a reserved name in CMake, and RTEMS_PREFIX is also a little bit more explicit. It is now possible to set a separate BSP path by supplying RTEMS_PATH and a different tools path by supplying RTEMS_TOOLS like suggested. Maybe CMake can also read the .pc pkgfiles in some way to determine compiler/linker flags automatically, at least Kitware has a module like this https://github.com/Kitware/CMake/blob/master/Modules/FindPkgConfig.cmake . Kind Regards Robin On Fri, 11 Dec 2020 at 11:14, Robin Müller <robin.muelle...@gmail.com> wrote: > Hi, > > There seems to be positive feedback, thanks for that. > > I can adapt the naming to be more consistent with your system. > My system is currently assuming that the RTEMS tools and the BSP are both > located at RTEMS_INST > I guess the first command: > > cmake -DPREFIX=/install-point -DRTEMS_BSP=arm/stm32h7 > > Would have the purpose to install the BSP itself? Right now, I also used > the tools path to autodetermine the RTEMS version > if the version is not supplied manually.cmake by extracting the last > number in the supplied RTEMS_INST path. > > I have not really thought about the install process yet, I simply built > the binary in a separate folder out of source like normally done in CMake. > But this should generally be possible, CMake has an install command as > well and the install location can be set using CMAKE_INSTALL_PREFIX > > Is it possible to get the pkgconfig files without building the BSPs? That > would be good so more hardware configurations can be added without having > to build every BSP. > > Kind Regards > Robin > > On Fri, 11 Dec 2020 at 10:59, Stanislav Pankevich <s.pankev...@gmail.com> > wrote: > >> Hi all, >> >> > I was wondering whether CMake support or an example is available or >> will be added in the future. We are using a framework which has different >> abstraction layers for OSes like (embedded) Linux, RTEMS and FreeRTOS, but >> we would like to use the same build system to build applications and right >> now CMake is our favourite because other tools like the Catch2 test >> framework are also built with CMake and there is a lot more >> documentation available for CMake. >> >> I would like to share our (PTS GmbH, Berlin) experience of using CMake >> with RTEMS. Our case is similar to that of Robin Müller's and our own >> software is all CMake-based. An additional advantage for using CMake for us >> is that the NASA cFS framework has recently switched to CMake so it is much >> easier to integrate it into the existing CMake tree. Another integration >> exercise that we had done before was to build RTEMS and DLR Outpost with >> CMake and that was also quite straightforward in spite of the fact the DLR >> Outpost didn't have a CMake layer. >> >> ~1 year ago we have captured all the RTEMS compilation and linking >> commands done by Autoconf for building the ARM-based BSP and converted them >> into CMakeLists.txt files. At that time, we didn't know how exactly the >> existing build system worked, so we were very careful and created many >> CMakeLists files, one for a folder (example: cpukit/libmisc/cpuuse or our >> own BSP folder). Our setup in the end is not 3 files but 60 files but the >> idea is the same: configs are collected in a few files, the rest are simply >> assigning source files to object/library targets. No changes are made to >> RTEMS source or build files. Instead, we keep all CMake scripts in a >> separate folder called: rtems-cmake-integration. >> >> One of the problems we see with this approach is updating to newer >> versions of RTEMS. If the CMake files do not co-exist with the RTEMS >> development tree, then it might be a manual exercise every time to make >> sure that the CMake integration layer always reflects what the developers >> of RTEMS intend it to be. Having this said, our 1-year-old CMake setup has >> been very stable so far, so we might as well stick with it for the time >> being. >> >> Having this said, I would like to avoid pushing the CMake-way of doing >> things as a better way. Instead, I could contribute feedback to Robin's >> work here: https://github.com/rmspacefish/rtems-cmake. For example, I >> could do the exercise of using his Just 3 files to see if our embedded >> target would compile and run. No hard promises about the time frames though >> until the Christmas holidays :) >> >> Thank you for your attention. >> >> On Fri, Dec 11, 2020 at 1:15 AM Joel Sherrill <j...@rtems.org> wrote: >> >>> >>> >>> On Thu, Dec 10, 2020 at 5:58 PM Chris Johns <chr...@rtems.org> wrote: >>> >>>> On 11/12/20 8:51 am, Robin Müller wrote: >>>> > Hello, >>>> > >>>> > I created a repository on github for the first version of what a >>>> CMake support >>>> > for RTEMS might look like: >>>> > >>>> > https://github.com/rmspacefish/rtems-cmake >>>> > <https://github.com/rmspacefish/rtems-cmake> >>>> > >>>> >>>> Awesome and thanks. :) >>>> >>> >>> Agreed. Bear with us being picky. We want things to be as >>> consistent as possible across BSPs, architectures, RTEMS versions, >>> and (hopefully) build systems. >>> >>> >>>> > I tried to extract generic components like determining library paths >>>> into >>>> > functions (RTEMSGeneric.cmake) >>>> > and there is a hardware specific file where flags for specific >>>> > BSPs/Architectures can be set (RTEMSHardware.cmake). >>>> > >>>> > I was able to compile both the hello project and my STM32 blinky >>>> project with >>>> > really similar and short CMake files which simply call >>>> rtems_general_config. >>>> > with a simple command like >>>> > >>>> > cmake -DRTEMS_INST=$RTEMS_INST -DRTEMS_BSP=arm/stm32h7 >>>> >>>> Would it be possible to align the naming to be consistent with the >>>> names we >>>> currently have? We use --rtems-tools for the path to the tools so would >>>> RTEMS_TOOLS work? >>>> >>>> We also provide the ability to specify where RTEMS (the RTEMS BSP) is >>>> installed. >>>> In some configurations we have a prefix, where the application or >>>> library being >>>> built are installed plus the RTEMS tools path and the RTEMS BSP path. >>>> They can >>>> all be the same or different. >>>> >>>> I am not sure what cmake does for the prefix so I will use PREFIX in my >>>> examples: >>>> >>>> cmake -DPREFIX=/install-point -DRTEMS_BSP=arm/stm32h7 >>>> >>>> Internally RTEMS_TOOLS and RTEMS would be set to PREFIX. >>>> >>>> cmake -DPREFIX=/install-point -DRTEMS_TOOLS=/tools-path >>>> -DRTEMS_BSP=arm/stm32h7 >>>> >>>> RTEMS_TOOLS is defined and RTEMS is set to RTEMS_TOOLS. >>>> >>>> Finally we can have: >>>> >>>> cmake -DPREFIX=/install-path \ >>>> -DRTEMS_TOOLS=/tools-path >>>> -DRTEMS=/bsp-path \ >>>> -DRTEMS_BSP=arm/stm32h7 >>>> >>>> All are left as defined on the command line. >>>> >>>> We have this separation so you can build a set of tools and build >>>> different >>>> branches of RTEMS and then different branches of the application or >>>> library for >>>> any of those combinations. A typical user will use the first or second >>>> option >>>> and if testing new releases or versions you can separate out the >>>> various paths. >>>> Separating the paths lets you some parts without having to build all >>>> the parts. >>>> >>>> > or >>>> > >>>> > cmake -DRTEMS_INST=$RTEMS_INST -DRTEMS_BSP=sparc/erc32 >>>> > >>>> > and then cmake --build . >>>> > >>>> > I made a test repository containing everything : >>>> > https://github.com/rmspacefish/rtems-demo >>>> > <https://github.com/rmspacefish/rtems-demo> >>>> > >>>> > Maybe this could be a part of the RTEMS repositories? >>>> >>>> This could be possible. It will come down to people using the package >>>> and the >>>> demand. The rtems_waf package is a top level RTEMS repo because it is >>>> used in >>>> libbsd and examples. >>>> >>>> The rtems-examples repo maybe be a good place to look at adding support >>>> and >>>> making it visible to the wider RTEMS community. I am not sure if this >>>> would be a >>>> submodule to github or not. I would love to hear what others think. >>>> >>> >>> If it is just an example, I'd prefer not to have another git repo. But >>> if it turns out >>> to work like the waf where you can close the rtems_cmake repo as a >>> submodule, >>> execute a couple of commands, and poof you can build an application, I'd >>> be ok >>> with it being a repo. I hope that makes sense -- example vs reusable >>> infrastructure. >>> >>> Thinking long term, when we have examples, not infrastructure, >>> rtems-examples could have a build_systems subdirectory and >>> then cmake, meson, scons, etc. >>> >>>> >>>> > In any case, I think it >>>> > can help people who would like to build their application >>>> > with CMake. The hello world example for CMake would be similar to >>>> building the >>>> > waf example for the sparc/erc32, with the difference that the >>>> > CMake support would have to be cloned and the build commands are a >>>> little bit >>>> > different. >>>> >>>> This is a really great start and I thank you for it. We are open to >>>> supporting >>>> all build systems. It is about individuals providing the support and >>>> then being >>>> thee to maintain it over a period of time. >>>> >>> >>> +1 >>> >>> --joel >>> >>>> >>>> Chris >>>> _______________________________________________ >>>> devel mailing list >>>> devel@rtems.org >>>> http://lists.rtems.org/mailman/listinfo/devel >>> >>> _______________________________________________ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >> >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
