CMake support

Robin Müller robin.mueller.m at gmail.com
Fri Dec 11 19:09:21 UTC 2020 

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.mueller.m at 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.pankevich at 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 <joel at rtems.org> wrote:
>>
>>>
>>>
>>> On Thu, Dec 10, 2020 at 5:58 PM Chris Johns <chrisj at 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 at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201211/f59d5f15/attachment-0001.html>

More information about the devel mailing list