CMake support

[Joel Sherrill]

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