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