On Thu, Dec 10, 2020 at 5:58 PM Chris Johns <chr...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel