Remaining Waf Conversion Tickets for Community and GSoC Students

[Joel Sherrill]

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.

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

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.

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210210/83ad6751/attachment.html>