Waf Build System Status in RTEMS?

Hesham Almatary heshamelmatary at gmail.com
Tue Feb 25 10:00:32 UTC 2020


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

> Chris


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



-- 
Hesham


More information about the devel mailing list