Remaining Waf Conversion Tickets for Community and GSoC Students

Chris Johns chrisj at rtems.org
Thu Feb 11 21:46:57 UTC 2021


On 11/2/21 7:50 pm, Sebastian Huber wrote:
> On 11/02/2021 00:20, Chris Johns wrote:
> 
>> On 10/2/21 4:20 pm, Sebastian Huber 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.
>> This idea has real merit and it is pragmatic. Keeping rtems-central as python3
>> makes sense and it also makes sense to not pollute it with python2 code.
>>
>> Sebastian are you able to have rtems-central export the needed files to the
>> rtemstoolkit in rtems-tools?
>>
> One option is to simply copy
> 
> https://git.rtems.org/rtems-central/tree/rtemsspec/items.py
> 
> to somewhere in rtems-tools. This module depends on the yaml module.

I am fine with adding the python YAML module to rtems-tools.

> Another option would be to use a special waf command (similar to bsp_defaults),
> to output the information for the BSP builder in JSON format.

This could work but I am concerned wrapping this around waf may add a layer of
complexity. When it works it is fine but a wrapper in rtems-tools would also
need to handle all the regenerate message, waf general output, errors and
failure conditions? A tools needs to be robust with invalid data, ie some messed
up specs files. We would need to test a number of exec combinations such as
Windows, python 2, 3, virtual env, etc to make sure this works. It seems like a
lot of work.

Importing a python module of shared and common code seems simpler to me.

I under the subtle complexity around the time it takes to load the spec files
and the pickled data currently supportedf. I wonder how much faster a C or C++
YAML reader would be?

I see a number of tools we can add to help users interact with this new build
configuration data. Having a means to import and use this data seems important
to me.

Chris


More information about the devel mailing list