On Thu, Sep 17, 2020 at 7:09 AM Joel Sherrill <j...@rtems.org> wrote: > > > > On Thu, Sep 17, 2020 at 3:54 AM Sebastian Huber > <sebastian.hu...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
