3rd party package build system

[Joel Sherrill]

On Mon, Sep 11, 2017 at 7:26 AM, Nicolas Tsiogkas <lou.nick at gmail.com>
wrote:

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

Hopefully it is not much and it is ways in which they assumed Linux not
POSIX
or not deeply embedded. Feel free to ask questions on issues. You tend to
see similar issues over and over.


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

>From a porting perspective, I would not worry about this. The package
should be written to the
standard networking APIs. The legacy stack or libbsd will have the same
core APIs although
libbsd will have a more complete set and have a more recent and robust set
of device drivers.

NOTE: The pc support needs updating. It broke when the core libbsd code was
last
updated to be using a later FreeBSD version. There should be a ticket
describing
the issue. I don't know if this impacts you or not.


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

Yes. The stack in the RTEMS tree is an older FreeBSD port with IPV4 only
and a limited set of newer device drivers. A lot of the older BSPs have
device
drivers for it. It is missing a few POSIX network APIs  but that doesn't
seem to
have ever caused anyone issues.

The new libbsd stack is much more modern, feature, uses standard FreeBSD
network drivers, IPV4, IPV6, etc. It also includes USB host and early Wifi
support.

If at all possible you want to use the libbsd stack. But for the purposes
of porting/compiling alone, it doesn't matter much. Thanks to careful
engineering, with RTEMS you use the same header files independent
of the underlying stack. Port to one and you should have a port to
the other until it comes to actual network configuration issues.

--joel


>
> 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
>>>
>>
>>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170911/916d799f/attachment-0002.html>