On Wed, Feb 10, 2021 at 9:20 AM Joel Sherrill <j...@rtems.org> wrote:
> > > On Wed, Feb 10, 2021 at 9:58 AM Gedare Bloom <ged...@rtems.org> wrote: > >> 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. >> > > 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. > > Ok. RSB is higher priority. From what I can tell, the BSP Builder has at most 2 users ;) And if they want it to work, they might need to pony up. > >> > 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. > > I'm not really convinced either way yet, and this discussion is getting off-topic. We should probably have a new thread to compare/discuss these two directions. > >> > 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