CMake support

Fri Dec 11 10:14:18 UTC 2020

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/850ea814/attachment.html>