3rd party package build system

Tue Sep 19 08:08:18 UTC 2017

Hi,

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:
'/home/niko/rtems/rsb/rtems/build/tmp/soem-sparc-rtems4.11-1-root-niko'
Build Set: Time 0:00:02.307659
Build FAILED

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.

Cheers,
Niko

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
> 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/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-0002.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-0002.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-0002.obj>