3rd party package build system

Nicolas Tsiogkas lou.nick at gmail.com
Thu Sep 7 15:40:34 UTC 2017

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.


On Thu, Sep 7, 2017 at 3:57 AM, Chris Johns <chrisj at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170907/2f465d46/attachment.html>

More information about the devel mailing list