3rd party package build system

[Nicolas Tsiogkas]

Hi Chris,

minor update on the progress.

I managed to start the compilation correctly on Friday. Of course it fails
as the source needs to be modified.

On that front I haven't heard back from people responsible for the ethernet
driver and if libbsd is in their scope.

In general which are the options? Libbsd and standard RTEMS networking
stack? I will try to evaluate both and have something compiling by Friday
hopefully, so I can test and create the patches.

Cheers,
Niko

On Thu, Sep 7, 2017 at 5:40 PM, Nicolas Tsiogkas <lou.nick at gmail.com> wrote:

> 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/ticke
>> t/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/20170911/50889580/attachment.html>