3rd party package build system

[Nicolas Tsiogkas]

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 <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-0002.html>