On Wed, Feb 10, 2021 at 10:27 AM Gedare Bloom <ged...@rtems.org> wrote:
> > > 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. > My scripting before only had 1 user so that makes a 200% increase in users. :) Seriously, it is a linchpin in quality. We would not notice if most BSPs break building otherwise. This ignores investigating BSP test run failures and fixing them. Chris and I were whining together about this recently. ( > > >> >>> > 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