<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 17, 2020 at 3:54 AM 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">On 17/09/2020 01:34, Chris Johns wrote:<br>
<br>
> On 17/9/20 8:12 am, Joel Sherrill wrote:<br>
>> Just noting that it would be nice to have a transition period where RTEMS BSP<br>
>> Builder supported both build systems for comparison purposes.<br>
> I prefer this be as short as possible. What about 1st Nov 2020?<br></blockquote><div><br></div><div>I don't want it to go on forever ever but that is only 6 weeks from today. </div><div><br></div><div>But OTOH, I know that rapidly will turn into the end of the calendar year.</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">
<br>
I added a ticket for this:<br>
<br>
<a href="https://devel.rtems.org/ticket/4081" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/4081</a></blockquote><div><br></div><div>Thank you.</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>
><br>
> It is not clear what the criteria is to trigger removal of the old build system.<br>
> We do not want a set of rules that are difficult to meet stalling the removal.<br>
><br>
> If you would like to meet some criteria please documented it on this page:<br>
><br>
> <a href="https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist</a><br>
><br>
> The columns in the table are the checklists but there are no rules on what needs<br>
> to be completed. It was intended to be a status.<br></blockquote><div><br></div><div>Chris and I chatted briefly about this but are there any automated ways to compare</div><div>the executables or objects themselves -- contents so timestamps and paths won't</div><div>matter. </div><div><br></div><div>If not, we are only going to be able to do what we have traditionally done which</div><div>is build everything in multiple configurations to ensure no build breakages. </div><div>Test what we can and be willing to go back to the 5 release branch for comparison</div><div>when something is reported broken in the future.</div><div><br></div><div>No matter what we do, I think it is safe to assume something will break somewhere</div><div>and someone will not discover it until well after we close the review period. We</div><div>might as well plan for that.</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>
> The new build system is way better to work with and if a user reports an issue<br>
> we should be able to sort it out. The 5.1 release is the old build system base<br>
> line once it is removed from master.<br>
<br>
It is critical to run the tests generated by the new build system. To <br>
run the build alone is not enough. For example, the i386 BSPs were <br>
completely broken since they used some special stuff in the *.cfg files.<br></blockquote><div><br></div><div>My build sweep runs tests for every BSP that has a simulator. There</div><div>is only one PC various in rtems-tester. If we need more to account for</div><div>variations, that's an issue.</div><div><br></div><div>And thinking about it, I only test one PC BSP variant. I should probably</div><div>add all of them just to be safer for this transition.</div><div><br></div><div>Also, the RISC-V BSPs didn't build unless the dl issue has been resolved</div><div>since my last run.</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>
A known issue is the -fdata-sections and -ffunction-sections handling in <br>
libbsd.<br>
<br>
</blockquote></div></div>