3rd party package build system

Thu Nov 9 15:22:21 UTC 2017

Hi all,

any news on this?

Managed to run SOEM on qemu with some help. It was on an arm guest and
successfully talked to 3 slaves.

I will try to push the SOEM changes upstream as well this week.

Cheers,
Niko.

On Tue, Sep 19, 2017 at 10:08 AM, Nicolas Tsiogkas <lou.nick at gmail.com>
wrote:

> 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/20171109/30f2581b/attachment-0001.html>