On Wed, Feb 10, 2021 at 7:28 AM Joel Sherrill <j...@rtems.org> wrote: > > > > On Tue, Feb 9, 2021 at 11:20 PM Sebastian Huber > <sebastian.hu...@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.hu...@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@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel