Remaining Waf Conversion Tickets for Community and GSoC Students
Chris Johns
chrisj at rtems.org
Wed Feb 10 23:30:58 UTC 2021
On 11/2/21 3:19 am, Joel Sherrill wrote:
> On Wed, Feb 10, 2021 at 9:58 AM Gedare Bloom <gedare at rtems.org
> <mailto:gedare at rtems.org>> wrote:
> On Wed, Feb 10, 2021 at 7:28 AM Joel Sherrill <joel at rtems.org
> <mailto:joel at rtems.org>> wrote:
> > On Tue, Feb 9, 2021 at 11:20 PM Sebastian Huber
> <sebastian.huber at embedded-brains.de
> <mailto:sebastian.huber at embedded-brains.de>> wrote:
> >> On 08/02/2021 10:40, Chris Johns wrote:
> >
> > This brings up a discussion I have been having with Kinsey. He submitted BSP
> > variants for the aarch64 ilp32 and ip64 multilibs but is heading to making
> those
> > BSP configure options. Not exposing them as variants makes them harder to
> test.
> > It is all the same code and same rtems-tester configuration information.
> >
> +1
>
> > Would we rather have BSP variants for something like this or have to layer on
> > more code to tweak BSP specific configure options when it really does
> matter to
> > the code generated?
> >
> > I am happy with clock speeds, memory address ranges, and RAM size being
> > configure options we don't push through automated testing. Hit the defaults
> > and move along. But configure options that substantially change builds like
> > switching the multilib variant feels different.
> >
> I think a good litmus test is whether or not the source code has to change.
>
> No source code change for Kinsey's BSPs -- just different GCC settings.
Do these settings change the ABI? I think we need to be careful having options
to vary a BSP's ABI with the same name.
Chris
More information about the devel
mailing list