3rd party package build system

Nicolas Tsiogkas lou.nick at gmail.com
Tue Sep 19 08:08:18 UTC 2017


I made the required changes and got SOEM to compile. It is still untested
and I'm getting the following error, but the library builds well.

RTEMS Source Builder - Set Builder, 4.11 (7db7be3ae7e0 modified)
Build Set: 4.11/net/soem
config: net/soem.cfg
package: soem-sparc-rtems4.11-1
git: clone: git://github.com/lounick/SOEM.git -> sources/git/SOEM.git
git: checkout: git://github.com/lounick/SOEM.git => integrate-with-RTEMS
building: soem-sparc-rtems4.11-1
error: copying tree:
/home/niko/rtems/rsb/rtems/build/tmp/soem-sparc-rtems4.11-1-root-niko ->
/home/niko/rtems/rsb/rtems/build/tmp/sb-niko/4.11/net/soem: [Errno 2] No
such file or directory:
Build Set: Time 0:00:02.307659

I will be attending a conference and won't be able to work on it till the
end of the month. I am attaching the patch plus the build log in case
someone has time to give it a try and find any issues. Else I will try to
test it once I'm back.


On Mon, Sep 11, 2017 at 3:19 PM, Joel Sherrill <joel at rtems.org> wrote:

> 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
> 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/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 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/20170919/50387d02/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: soem.patch
Type: text/x-patch
Size: 2984 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170919/50387d02/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log_erc32_soem
Type: application/octet-stream
Size: 27070 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170919/50387d02/attachment-0001.obj>

More information about the devel mailing list