Waf Build System Status in RTEMS?

[Sebastian Huber]

On 25/02/2020 11:00, Hesham Almatary wrote:
> On Mon, 24 Feb 2020 at 22:50, Chris Johns<chrisj at rtems.org>  wrote:
>> On 21/2/20 11:11 pm, Sebastian Huber wrote:
>>> On 21/02/2020 12:26, Hesham Almatary wrote:
>>>> On Fri, 21 Feb 2020 at 11:07, Sebastian Huber
>>>> <sebastian.huber at embedded-brains.de>   wrote:
>>>>> Hello Hesham,
>>>>>
>>>>> On 20/02/2020 16:40, Hesham Almatary wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Are there any progress updates to the Waf build system integration in RTEMS?
>>>>>>
>>>>>> I have pulled [1] and it seems like it hasn't got many updates since
>>>>>> December. I wonder what's still remaining/blocking to merge it, or at
>>>>>> least push it as a development branch (without re-writing history)
>>>>>> that others, including me, can use it and submit patches against.
>>>>>>
>>>>>> [1] git://git.rtems.org/sebh/rtems.git
>>>>> technically, the new build system is ready for integration into the
>>>>> master branch. I would need about one day to rebase and test it before
>>>>> the push. The integration is currently blocked since Chris and Joel had
>>>>> no time to look at it.
>>>>>
>>>> Thanks for your input, Sebastian. Is there a recommended branch I
>>>> should be based on? I noticed there's "build" and "build-next".
>>> The "build" branch contains the state of the first review. I updated
>>> "build-next" a couple of times to integrate the changes on the RTEMS master.
>>>
>>>> Do you intend to re-write git history in either?
>>> Yes, when I started with the build system work I didn't expect a more than two
>>> months review period.
>> I have discussed this merge with Joel. We have decided to release RTEMS 5 before
>> we merge a new build system. A release with parallel build systems is confusing
>> and distracting.
>>
> That makes sense to me. I think we should both try to push for an
> RTEMS release soon, and make the waf/build
> branch more stable and/or in the view (e.g., push as an experimental
> branch) for developer to use until a release comes out. I understand
> another branch would incur more maintaibility efforts, but it will
> also help make the the new build system more usable.

I can do a forced update of the "build" branch with my latest version 
based on rebase of the current master by the end of the week. 
Afterwards, I can do merges from the master instead of forced pushes. 
This should enable you to base your work on this branch. You can also 
send me patches.

Before the new build system is integrated in the master, I will do a 
final rebase to the master and squash commits.

> 
>> I think we are close to a release if master can stay stable. The milestone
>> ticket page ...
>>
>>   https://devel.rtems.org/milestone/5.1
>>
>> ... shows 43 in progress and 2 closed. Help with the tickets will help progress
>> things.
>>
>> I am working on moving the libbsd release to the 5-freebsd-12 branch and the
>> side effects that causes. I will need reports of a libbsd release snapshort
>> running on ...
>>
>>   beagleboneblack, imx7, xilinx_zynq_zedboard, qoriq_e500
>>
>> I can do this for the beagleboneblack and xilinx_zynq_zedboard.
>>
> I recently got libbsd working with RISC-V on QEMU. On my TODO list,
> I'll create a soft SoC with DTB/FDT and devices for testing on an FPGA
> board, I will report about that if I got some apps/tests reasonably
> working.
> 
>> Finally there is the FDT file managements, I would like a resolution on a
>> suitable path to get FDT files into a release and at least one BSP to support
>> this. I have selected the BeagleBone Black because I have one to test on.
>>
> I can pitch in with RISC-V (QEMU and/or FPGA SoCs/board). I'd like for
> FDT management to be as generic as could be across different
> BSPs/architectures.

The FreeBSD device tree support should be fairly architecture 
independent. However, it is not as good/complete/robust as the Linux 
device tree support. I am not in favour of adding an RTEMS-specific 
device tree support.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.