CMake support

Chris Johns chrisj at rtems.org
Thu Dec 10 23:58:32 UTC 2020


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. :)

> 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.

> 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.

Chris


More information about the devel mailing list