Remaining Waf Conversion Tickets for Community and GSoC Students

Wed Feb 10 16:27:05 UTC 2021

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.

>
>> > 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/381bc72a/attachment-0001.html>