Waf Build System Status in RTEMS?

[Hesham Almatary]

On Tue, 25 Feb 2020 at 11:54, Sebastian Huber
<sebastian.huber at embedded-brains.de> 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.
>
That will be great, thanks! I have WIP patches to both LLVM and
rtems/waf to build
for RISC-V BSPs. I'd like to move to rtems/waf in our local CI system
with our RTEMS
fork. Once I feel confident about those patches and tested them, I'll
submit them.

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

> >
> >> 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.
>
I might be more biased  to FreeBSD here, but I don't have strong
opinions about it yet.

> --
> 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.



--
Hesham