Remaining Waf Conversion Tickets for Community and GSoC Students

[Chris Johns]

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