<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 10, 2021 at 9:58 AM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Feb 10, 2021 at 7:28 AM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
><br>
><br>
><br>
> On Tue, Feb 9, 2021 at 11:20 PM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
>><br>
>><br>
>> On 08/02/2021 10:40, Chris Johns wrote:<br>
>> >> It is written in Python 3.6.<br>
>> > We still need to support python 2. Maybe having this file support both could be<br>
>> > part of the project.<br>
>> I think this BSP builder is a development tool which can use Python 3.<br>
>> It is useful to maintain RTEMS, but it is not a tool required for end<br>
>> users of RTEMS to develop applications. Independent of this, the Python<br>
>> 2 end of life was a year ago.<br>
><br>
><br>
> It is still the default Python on CentOS7 which is an even longer LTS release<br>
> based on the recent CentOS changes.  I would consider it a primary test tool<br>
> which should work on all hosts.<br>
><br>
<br>
I don't agree with the perspective. The BSP Builder is project<br>
infrastructure, but not really intended or used by users AFAIK. Only<br>
maintainers have any desire to build/test multiple architectures.<br></blockquote><div><br></div><div>At least I run the BSP builder once a week on CentOS, FreeBSD, and </div><div>Ubuntu and publish reports. It isn't user facing but it is a critical part of </div><div>our project infrastructure. I'm more concerned about it being switched </div><div>to waf than Python2/3 at the moment.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Virtually everyone else uses one at a time via the RSB. CentOS has<br>
never been a suitable development distro, it is stable for servers but<br>
quickly outdated for rolling development. Just because some maintainer<br>
may like it, does not strictly justify making project-level decisions<br>
to cater to it.<br>
<br>
Python 2 is EOL, regardless of what distributions are doing about it.<br>
We need to cut that off wherever it is sensible, to reduce our<br>
maintenance burden. That is my two cents.<br></blockquote><div><br></div><div>I wasn't complaining about Python2 support as much as saying</div><div>CentOS 7 will be available much longer than we think in large</div><div>enterprises that use RTEMS. Just need to figure out our approach.</div><div><br></div><div>I'm more concerned with the RSB kernel recipe and bsp builder</div><div>supporting waf. Those are immediate issues.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> And we are already seeing the impact of the bsp-builder not supporting waf:<br>
><br>
> <a href="https://lists.rtems.org/pipermail/build/2021-February/025640.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/build/2021-February/025640.html</a><br>
><br>
> 305 or ~1600 BSP builds failed because you can't build PowerPC BSPs<br>
> using autoconf.<br>
><br>
>><br>
>> ><br>
>> > Access to all the configure data makes a new problem for the BSP builder, being<br>
>> > able to vary all options a BSP has? We would not want to do this so what would<br>
>> > we want?<br>
>> It should be enough to test all BSP variants, everything else will face<br>
>> a combinatorial explosion.<br>
><br>
+1<br>
<br>
><br>
> This brings up a discussion I have been having with Kinsey. He submitted BSP<br>
> variants for the aarch64 ilp32 and ip64 multilibs but is heading to making those<br>
> BSP configure options. Not exposing them as variants makes them harder to test.<br>
> It is all the same code and same rtems-tester configuration information.<br>
><br>
+1<br>
<br>
> Would we rather have BSP variants for something like this or have to layer on<br>
> more code to tweak BSP specific configure options when it really does matter to<br>
> the code generated?<br>
><br>
> I am happy with clock speeds, memory address ranges, and RAM size being<br>
> configure options we don't push through automated testing. Hit the defaults<br>
> and move along. But configure options that substantially change builds like<br>
> switching the multilib variant feels different.<br>
><br>
I think a good litmus test is whether or not the source code has to change.<br></blockquote><div><br></div><div>No source code change for Kinsey's BSPs -- just different GCC settings.</div><div>And we can test both variants on qemu. There is also relatively inexpensive </div><div>hardware to run them on (when that documentation and tweaks is submitted). </div><div><br></div><div>So this is not a case where BSP source code changes, just the gcc options.</div><div><br></div><div>We have this case already in the RISC-V BSPs which have many multilib</div><div>variants. If this is the preferred approach, we need to document it and I</div><div>need to make sure Kinsey knows. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> What do we want the rules to be?<br>
>><br>
>><br>
>> --<br>
>> embedded brains GmbH<br>
>> Herr Sebastian HUBER<br>
>> Dornierstr. 4<br>
>> 82178 Puchheim<br>
>> Germany<br>
>> email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
>> phone: +49-89-18 94 741 - 16<br>
>> fax:   +49-89-18 94 741 - 08<br>
>><br>
>> Registergericht: Amtsgericht München<br>
>> Registernummer: HRB 157899<br>
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
>> Unsere Datenschutzerklärung finden Sie hier:<br>
>> <a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
>><br>
>> _______________________________________________<br>
>> devel mailing list<br>
>> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
><br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>