CMake support

Fri Dec 11 09:58:47 UTC 2020

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201211/2332a6b7/attachment-0001.html>