<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 9, 2021 at 11:20 PM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</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"><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></blockquote><div><br></div><div>It is still the default Python on CentOS7 which is an even longer LTS release</div><div>based on the recent CentOS changes.  I would consider it a primary test tool</div><div>which should work on all hosts.</div><div><br></div><div>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">https://lists.rtems.org/pipermail/build/2021-February/025640.html</a><br></div><div><br></div><div>305 or ~1600 BSP builds failed because you can't build PowerPC BSPs</div><div>using autoconf. </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>
> 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></blockquote><div><br></div><div>This brings up a discussion I have been having with Kinsey. He submitted BSP</div><div>variants for the aarch64 ilp32 and ip64 multilibs but is heading to making those</div><div>BSP configure options. Not exposing them as variants makes them harder to test.</div><div>It is all the same code and same rtems-tester configuration information.</div><div><br></div><div>Would we rather have BSP variants for something like this or have to layer on</div><div>more code to tweak BSP specific configure options when it really does matter to</div><div>the code generated?</div><div><br></div><div>I am happy with clock speeds, memory address ranges, and RAM size being</div><div>configure options we don't push through automated testing. Hit the defaults</div><div>and move along. But configure options that substantially change builds like</div><div>switching the multilib variant feels different.</div><div><br></div><div>What do we want the rules to be?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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></blockquote></div></div>