Remaining Waf Conversion Tickets for Community and GSoC Students

[Gedare Bloom]

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

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

> 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