Waf Build System Status in RTEMS?

[Chris Johns]

On 25/2/20 10:54 pm, Sebastian Huber wrote:
> 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.

What do you mean by "RTEMS-specific device tree support"? We have RTEMS support
for FDT in the kernel code and libbsd.

So again in case I was not making myself clear, I feel FDT support as it stands
is partially implemented and I regret not raising this before now. Having code
to load blobs and drivers that reference blobs is only one part of using FDT,
you need matching and valid FDT sources and blobs and this means we need to
manage the FDT source and maybe create blobs our code references (ie overlays).
As stated I am not in favor of documented URLs etc because they disappear or
change plus it breaks releases as it does not meet our long time requirement for
releases having all files contained in the release held on our servers.

This is blocking a release.

I am looking for solutions to this issue that we can work worth.

Chris