CMake support
Chris Johns
chrisj at rtems.org
Sun Dec 13 23:45:09 UTC 2020
On 11/12/20 9:14 pm, Robin Müller wrote:
>
> There seems to be positive feedback, thanks for that.
>
> I can adapt the naming to be more consistent with your system.
Thanks
> 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.
The path can be anything and there is no implied version number embedded in a
path. Detecting the RTEMS version that way is fragile. I suggest you set the
version major number in your scripts and they will need to be adjusted with each
major release. If this work becomes part of the RTEMS repo suite I would then
add this change to the list we have.
> 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.
Yes that is fine. Your work may not be about installing. Installing is about
those cmake projects that are installed. The use of a prefix is a convention
that implies a form of sandboxing. In this case all parts are in the same
directory tree.
Have you seen and read ...
https://docs.rtems.org/branches/master/user/installation/project-sandboxing.html
?
An application is often never installed and so providing a prefix to install is
something users do not consider. How ever consider cFS (NASA's core flight
software suite) that is built with cmake, it needs to install itself under a
prefix and in a know directory tree so tools and build systems that are not
cmake can access the header and library files. A prefix is important. An
application however can use the prefix to say the tools, BSP and any 3rd party
libraries can be found under it. It is nothing more than a convention to
describe a type of sandbox.
> But this should generally be possible, CMake has an install command as well and
> the install location can be set using CMAKE_INSTALL_PREFIX
Ah yes CMAKE_INSTALL_PREFIX is what cmake decided to use. This is fine to use
for the 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.
I think the kitware cmake pkgconfig reader in the other post is the path to follow.
Chris
>
> Kind Regards
> Robin
>
> On Fri, 11 Dec 2020 at 10:59, Stanislav Pankevich <s.pankevich at gmail.com
> <mailto: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
> <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
> <mailto:joel at rtems.org>> wrote:
>
>
>
> On Thu, Dec 10, 2020 at 5:58 PM Chris Johns <chrisj at rtems.org
> <mailto: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>
> > <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>
> > <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 <mailto:devel at rtems.org>
> http://lists.rtems.org/mailman/listinfo/devel
> <http://lists.rtems.org/mailman/listinfo/devel>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org <mailto:devel at rtems.org>
> http://lists.rtems.org/mailman/listinfo/devel
> <http://lists.rtems.org/mailman/listinfo/devel>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org <mailto:devel at rtems.org>
> http://lists.rtems.org/mailman/listinfo/devel
> <http://lists.rtems.org/mailman/listinfo/devel>
>
More information about the devel
mailing list