RTEMS BSP Builder and New/Old Build System

[Gedare Bloom]

On Thu, Sep 17, 2020 at 7:09 AM Joel Sherrill <joel at rtems.org> wrote:
>
>
>
> On Thu, Sep 17, 2020 at 3:54 AM Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
>>
>> On 17/09/2020 01:34, Chris Johns wrote:
>>
>> > On 17/9/20 8:12 am, Joel Sherrill wrote:
>> >> Just noting that it would be nice to have a transition period where RTEMS BSP
>> >> Builder supported both build systems for comparison purposes.
>> > I prefer this be as short as possible. What about 1st Nov 2020?
>
>
> I don't want it to go on forever ever but that is only 6 weeks from today.
>
> But OTOH, I know that rapidly will turn into the end of the calendar year.
>
>>
>> I added a ticket for this:
>>
>> https://devel.rtems.org/ticket/4081
>
>
> Thank you.
>
>>
>>
>> >
>> > It is not clear what the criteria is to trigger removal of the old build system.
>> > We do not want a set of rules that are difficult to meet stalling the removal.
>> >
>> > If you would like to meet some criteria please documented it on this page:
>> >
>> > https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist
>> >
>> > The columns in the table are the checklists but there are no rules on what needs
>> > to be completed. It was intended to be a status.
>
>
> Chris and I chatted briefly about this but are there any automated ways to compare
> the executables or objects themselves -- contents so timestamps and paths won't
> matter.
>
I think the link order has changed. I used 'size' and saw that .text
differs, and then nm and see some symbols are put in different
locations between the two builds. This leads to some differences due
to padding etc. So it will be hard to make this comparison.


> If not, we are only going to be able to do what we have traditionally done which
> is build everything in multiple configurations to ensure no build breakages.
> Test what we can and be willing to go back to the 5 release branch for comparison
> when something is reported broken in the future.
>
> No matter what we do, I think it is safe to assume something will break somewhere
> and someone will not discover it until well after we close the review period. We
> might as well plan for that.
>
>>
>> >
>> > The new build system is way better to work with and if a user reports an issue
>> > we should be able to sort it out. The 5.1 release is the old build system base
>> > line once it is removed from master.
>>
>> It is critical to run the tests generated by the new build system. To
>> run the build alone is not enough. For example, the i386 BSPs were
>> completely broken since they used some special stuff in the *.cfg files.
>
>
> My build sweep runs tests for every BSP that has a simulator. There
> is only one PC various in rtems-tester. If we need more to account for
> variations, that's an issue.
>
> And thinking about it, I only test one PC BSP variant. I should probably
> add all of them just to be safer for this transition.
>
> Also, the RISC-V BSPs didn't build unless the dl issue has been resolved
> since my last run.
>
>>
>>
>> A known issue is the -fdata-sections and -ffunction-sections handling in
>> libbsd.
>>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel