RTEMS BSP Builder and New/Old Build System
joel at rtems.org
Thu Sep 17 13:07:54 UTC 2020
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:
> > It is not clear what the criteria is to trigger removal of the old build
> > We do not want a set of rules that are difficult to meet stalling the
> > If you would like to meet some criteria please documented it on this
> > 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
the executables or objects themselves -- contents so timestamps and paths
If not, we are only going to be able to do what we have traditionally done
is build everything in multiple configurations to ensure no build
Test what we can and be willing to go back to the 5 release branch for
when something is reported broken in the future.
No matter what we do, I think it is safe to assume something will break
and someone will not discover it until well after we close the review
might as well plan for that.
> > The new build system is way better to work with and if a user reports an
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel