Thanks Chris for your input. I think I've used a cmake gui once in 2008 or 2009 and never did that to myself again. :P
I started creating the required cmake extensions for SOEM. I hope to have something trying to compile by monday sometime. I'll keep you posted. Cheers, Niko On Thu, Sep 7, 2017 at 3:57 AM, Chris Johns <chr...@rtems.org> wrote: > On 06/09/2017 19:56, Nicolas Tsiogkas wrote: > > I'm trying to integrate SOEM with RTEMS (https://devel.rtems.org/ > ticket/3120 > > <https://devel.rtems.org/ticket/3120>) > > Thank you for creating the ticket. > > > As I am trying to create the appropriate bset and cfg files I noticed > that all > > the packages built are based on autoconf to be built. > > This reflects the nature of the packages we currently support and nothing > more. > > > SOEM on the other hand is only providing CMake as a build tool. > > This should be fine if the implementation in SOEM is ok. > > > I have found instructions on using CMake with RTEMS > > (https://lists.rtems.org/pipermail/devel/2016-March/013800.html) > > > > The question is if it would be more sensible to create a build > environment for > > SOEM based on autotools or try to use CMake somehow? > > I do not think there is a need. The upstream project has selected cmake > and we > should respect that. > > > I doubt that changing the build system will be easily accepted upstream. > > Agreed. > > The RSB scripts will invoke cmake so this bit is easy. The part you need > to work > with the upstream project is getting a cross-complier build to work. How > well > this works depends on how the cmake build scripts in the project are > implemented. Carefully constructed cmake build scripts and the judicious > use of > the command line `-D` options can be used to configure and/or build the > package. > > I should warn you, use the cmake gui and tui tool at your own risk, if you > step > in there you may never return as the same person. > > The key file in the RSB is rtems-bsp.cfg [1]. It wraps a private package > config > implementation that parses an installed BSP's build configuration [2] and > updates the internal RSB data [3]. > > I suggest you get the package to build from the command line for a BSP. > This > will be the compiler name and cflags. What you end up with will be > available in > the macros in rtems-bsp.cfg. > > Have a look in the BSP installed .pc file for the flags to use, ie do a > `find . > -name \*.pc` from the RTEMS installed prefix path. > > My (publicly denied) cmake experience with RTEMS is configure header tests > can > be fragile if there is cmake nesting. > > Chris > > [1] https://git.rtems.org/rtems-source-builder/tree/rtems/ > config/rtems-bsp.cfg > [2] https://git.rtems.org/rtems-source-builder/tree/rtems/ > config/rtems-bsp.cfg#n64 > [3] https://git.rtems.org/rtems-source-builder/tree/rtems/ > config/rtems-bsp.cfg#n81 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel