Remaining Waf Conversion Tickets for Community and GSoC Students

Wed Feb 10 16:42:53 UTC 2021

On Wed, Feb 10, 2021 at 10:27 AM Gedare Bloom <gedare at rtems.org> wrote:

>
>
> On Wed, Feb 10, 2021 at 9:20 AM Joel Sherrill <joel at rtems.org> wrote:
>
>>
>>
>> On Wed, Feb 10, 2021 at 9:58 AM Gedare Bloom <gedare at rtems.org> wrote:
>>
>>> On Wed, Feb 10, 2021 at 7:28 AM Joel Sherrill <joel at rtems.org> wrote:
>>> >
>>> >
>>> >
>>> > On Tue, Feb 9, 2021 at 11:20 PM Sebastian Huber <
>>> sebastian.huber at embedded-brains.de> wrote:
>>> >>
>>> >>
>>> >> On 08/02/2021 10:40, Chris Johns wrote:
>>> >> >> It is written in Python 3.6.
>>> >> > We still need to support python 2. Maybe having this file support
>>> both could be
>>> >> > part of the project.
>>> >> I think this BSP builder is a development tool which can use Python 3.
>>> >> It is useful to maintain RTEMS, but it is not a tool required for end
>>> >> users of RTEMS to develop applications. Independent of this, the
>>> Python
>>> >> 2 end of life was a year ago.
>>> >
>>> >
>>> > It is still the default Python on CentOS7 which is an even longer LTS
>>> release
>>> > based on the recent CentOS changes.  I would consider it a primary
>>> test tool
>>> > which should work on all hosts.
>>> >
>>>
>>> I don't agree with the perspective. The BSP Builder is project
>>> infrastructure, but not really intended or used by users AFAIK. Only
>>> maintainers have any desire to build/test multiple architectures.
>>>
>>
>> At least I run the BSP builder once a week on CentOS, FreeBSD, and
>> Ubuntu and publish reports. It isn't user facing but it is a critical
>> part of
>> our project infrastructure. I'm more concerned about it being switched
>> to waf than Python2/3 at the moment.
>>
>> Virtually everyone else uses one at a time via the RSB. CentOS has
>>> never been a suitable development distro, it is stable for servers but
>>> quickly outdated for rolling development. Just because some maintainer
>>> may like it, does not strictly justify making project-level decisions
>>> to cater to it.
>>>
>>> Python 2 is EOL, regardless of what distributions are doing about it.
>>> We need to cut that off wherever it is sensible, to reduce our
>>> maintenance burden. That is my two cents.
>>>
>>
>> I wasn't complaining about Python2 support as much as saying
>> CentOS 7 will be available much longer than we think in large
>> enterprises that use RTEMS. Just need to figure out our approach.
>>
>> I'm more concerned with the RSB kernel recipe and bsp builder
>> supporting waf. Those are immediate issues.
>>
>>
> Ok. RSB is higher priority. From what I can tell, the BSP Builder has at
> most 2 users ;) And if they want it to work, they might need to pony up.
>

My scripting before only had 1 user so that makes a 200% increase in users.
:)

Seriously, it is a linchpin in quality. We would not notice if most BSPs
break
building otherwise.

This ignores investigating BSP test run failures and fixing them. Chris and
I
were whining together about this recently. (

>
>
>>
>>> > And we are already seeing the impact of the bsp-builder not supporting
>>> waf:
>>> >
>>> > https://lists.rtems.org/pipermail/build/2021-February/025640.html
>>> >
>>> > 305 or ~1600 BSP builds failed because you can't build PowerPC BSPs
>>> > using autoconf.
>>> >
>>> >>
>>> >> >
>>> >> > Access to all the configure data makes a new problem for the BSP
>>> builder, being
>>> >> > able to vary all options a BSP has? We would not want to do this so
>>> what would
>>> >> > we want?
>>> >> It should be enough to test all BSP variants, everything else will
>>> face
>>> >> a combinatorial explosion.
>>> >
>>> +1
>>>
>>> >
>>> > 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.
>> And we can test both variants on qemu. There is also relatively
>> inexpensive
>> hardware to run them on (when that documentation and tweaks is
>> submitted).
>>
>> So this is not a case where BSP source code changes, just the gcc options.
>>
>> We have this case already in the RISC-V BSPs which have many multilib
>> variants. If this is the preferred approach, we need to document it and I
>> need to make sure Kinsey knows.
>>
>>
>
> I'm not really convinced either way yet, and this discussion is getting
> off-topic. We should probably have a new thread to compare/discuss these
> two directions.
>
>
>>
>>> > What do we want the rules to be?
>>> >>
>>> >>
>>> >> --
>>> >> embedded brains GmbH
>>> >> Herr Sebastian HUBER
>>> >> Dornierstr. 4
>>> >> 82178 Puchheim
>>> >> Germany
>>> >> email: sebastian.huber at embedded-brains.de
>>> >> phone: +49-89-18 94 741 - 16
>>> >> fax:   +49-89-18 94 741 - 08
>>> >>
>>> >> Registergericht: Amtsgericht München
>>> >> Registernummer: HRB 157899
>>> >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas
>>> Dörfler
>>> >> Unsere Datenschutzerklärung finden Sie hier:
>>> >> https://embedded-brains.de/datenschutzerklaerung/
>>> >>
>>> >> _______________________________________________
>>> >> devel mailing list
>>> >> devel at rtems.org
>>> >> http://lists.rtems.org/mailman/listinfo/devel
>>> >
>>> > _______________________________________________
>>> > devel mailing list
>>> > devel at rtems.org
>>> > http://lists.rtems.org/mailman/listinfo/devel
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210210/6ab33b50/attachment.html>