Remaining Waf Conversion Tickets for Community and GSoC Students

Wed Feb 10 16:19:41 UTC 2021

On Wed, Feb 10, 2021 at 9:58 AM Gedare Bloom <gedare at rtems.org> wrote:

> On Wed, Feb 10, 2021 at 7:28 AM Joel Sherrill <joel at rtems.org> wrote:
> >
> >
> >
> > On Tue, Feb 9, 2021 at 11:20 PM Sebastian Huber <
> sebastian.huber at embedded-brains.de> wrote:
> >>
> >>
> >> On 08/02/2021 10:40, Chris Johns wrote:
> >> >> It is written in Python 3.6.
> >> > We still need to support python 2. Maybe having this file support
> both could be
> >> > part of the project.
> >> I think this BSP builder is a development tool which can use Python 3.
> >> It is useful to maintain RTEMS, but it is not a tool required for end
> >> users of RTEMS to develop applications. Independent of this, the Python
> >> 2 end of life was a year ago.
> >
> >
> > It is still the default Python on CentOS7 which is an even longer LTS
> release
> > based on the recent CentOS changes.  I would consider it a primary test
> tool
> > which should work on all hosts.
> >
>
> I don't agree with the perspective. The BSP Builder is project
> infrastructure, but not really intended or used by users AFAIK. Only
> maintainers have any desire to build/test multiple architectures.
>

At least I run the BSP builder once a week on CentOS, FreeBSD, and
Ubuntu and publish reports. It isn't user facing but it is a critical part
of
our project infrastructure. I'm more concerned about it being switched
to waf than Python2/3 at the moment.

Virtually everyone else uses one at a time via the RSB. CentOS has
> never been a suitable development distro, it is stable for servers but
> quickly outdated for rolling development. Just because some maintainer
> may like it, does not strictly justify making project-level decisions
> to cater to it.
>
> Python 2 is EOL, regardless of what distributions are doing about it.
> We need to cut that off wherever it is sensible, to reduce our
> maintenance burden. That is my two cents.
>

I wasn't complaining about Python2 support as much as saying
CentOS 7 will be available much longer than we think in large
enterprises that use RTEMS. Just need to figure out our approach.

I'm more concerned with the RSB kernel recipe and bsp builder
supporting waf. Those are immediate issues.

>
> > And we are already seeing the impact of the bsp-builder not supporting
> waf:
> >
> > https://lists.rtems.org/pipermail/build/2021-February/025640.html
> >
> > 305 or ~1600 BSP builds failed because you can't build PowerPC BSPs
> > using autoconf.
> >
> >>
> >> >
> >> > Access to all the configure data makes a new problem for the BSP
> builder, being
> >> > able to vary all options a BSP has? We would not want to do this so
> what would
> >> > we want?
> >> It should be enough to test all BSP variants, everything else will face
> >> a combinatorial explosion.
> >
> +1
>
> >
> > This brings up a discussion I have been having with Kinsey. He submitted
> BSP
> > variants for the aarch64 ilp32 and ip64 multilibs but is heading to
> making those
> > BSP configure options. Not exposing them as variants makes them harder
> to test.
> > It is all the same code and same rtems-tester configuration information.
> >
> +1
>
> > Would we rather have BSP variants for something like this or have to
> layer on
> > more code to tweak BSP specific configure options when it really does
> matter to
> > the code generated?
> >
> > I am happy with clock speeds, memory address ranges, and RAM size being
> > configure options we don't push through automated testing. Hit the
> defaults
> > and move along. But configure options that substantially change builds
> like
> > switching the multilib variant feels different.
> >
> I think a good litmus test is whether or not the source code has to change.
>

No source code change for Kinsey's BSPs -- just different GCC settings.
And we can test both variants on qemu. There is also relatively inexpensive
hardware to run them on (when that documentation and tweaks is submitted).

So this is not a case where BSP source code changes, just the gcc options.

We have this case already in the RISC-V BSPs which have many multilib
variants. If this is the preferred approach, we need to document it and I
need to make sure Kinsey knows.

>
> > What do we want the rules to be?
> >>
> >>
> >> --
> >> embedded brains GmbH
> >> Herr Sebastian HUBER
> >> Dornierstr. 4
> >> 82178 Puchheim
> >> Germany
> >> email: sebastian.huber at embedded-brains.de
> >> phone: +49-89-18 94 741 - 16
> >> fax:   +49-89-18 94 741 - 08
> >>
> >> Registergericht: Amtsgericht München
> >> Registernummer: HRB 157899
> >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> >> Unsere Datenschutzerklärung finden Sie hier:
> >> https://embedded-brains.de/datenschutzerklaerung/
> >>
> >> _______________________________________________
> >> devel mailing list
> >> devel at rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
> >
> > _______________________________________________
> > 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/20210210/e931c038/attachment.html>