Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything

[Sebastian Huber]

On 15/10/2020 08:30, Chris Johns wrote:

> On 15/10/20 5:26 pm, Sebastian Huber wrote:
>> On 15/10/2020 08:23, Chris Johns wrote:
>>
>>> On 15/10/20 5:15 pm, Sebastian Huber wrote:
>>>> On 15/10/2020 08:05, Chris Johns wrote:
>>>>
>>>>> On 15/10/20 4:35 pm, Sebastian Huber wrote:
>>>>>> On 15/10/2020 00:48, Chris Johns wrote:
>>>>>>
>>>>>>> On 15/10/20 2:27 am, Joel Sherrill wrote:
>>>>>>>> On Wed, Oct 14, 2020 at 10:20 AM Sebastian Huber
>>>>>>>> <sebastian.huber at embedded-brains.de  
>>>>>>>> <mailto:sebastian.huber at embedded-brains.de>>
>>>>>>>> wrote:
>>>>>>>>         On 14/10/2020 17:17, Joel Sherrill wrote:
>>>>>>>>         > On Wed, Oct 14, 2020 at 9:45 AM Sebastian Huber
>>>>>>>>         > <sebastian.huber at embedded-brains.de
>>>>>>>>         <mailto:sebastian.huber at embedded-brains.de>
>>>>>>>>         > <mailto:sebastian.huber at embedded-brains.de
>>>>>>>>         <mailto:sebastian.huber at embedded-brains.de>>> wrote:
>>>>>>>>         >     On 14/10/2020 15:35, Joel Sherrill wrote:
>>>>>>>>         >
>>>>>>>>         >     > BSP builder has 81 failures. :(
>>>>>>>>         >     It tried to build BSPs which no longer exist.
>>>>>>>>         >
>>>>>>>>         > Well that is an easier thing to fix than my concern that it was
>>>>>>>> related to
>>>>>>>>         > giving errors when a BSP does not support a feature. I suppose that
>>>>>>>> will
>>>>>>>>         > show up when the bsp builder switches to waf.
>>>>>>>>         >
>>>>>>>>         > Can you patch ./config/rtems-bsps-tiers.ini to reflect what you
>>>>>>>> removed?
>>>>>>>>         We should try try to reduce the redundancy in our data sets. Why
>>>>>>>> don't
>>>>>>>>         we record the tier status in the BSP items?
>>>>>>>>
>>>>>>>> That's a Chris discussion when the builder is switched to using waf.
>>>>>>> The current data is in rtems-tools.git/config. I needed a spot and could not
>>>>>>> think of another place that was easy and low impact. I would welcome
>>>>>>> alternatives. If this data can be generated and updated or runtime loaded
>>>>>>> from
>>>>>>> another source, ie spec files, I would welcome this.
>>>>>>>
>>>>>>> The current blocker with the spec files is being able to use some shared
>>>>>>> code to
>>>>>>> parse and load the YAML data plus being able to load the data quickly. Waf
>>>>>>> has
>>>>>>> the loading code in the wscript file so that cannot be easily shared and it
>>>>>>> uses
>>>>>>> saved pickled data which I do not think is shareable.
>>>>>> We have a couple of options to re-use the build specification items. In
>>>>>> general,
>>>>>> the Python module to work with these items outside the wscript is in
>>>>>> rtems-central:
>>>>>>
>>>>>> https://git.rtems.org/rtems-central/tree/rtemsspec/items.py
>>>>> How long does this code take to load the build spec files in rtems.git?
>>>>>
>>>> It uses an item cache in pickle format. If you start with an empty cache it
>>>> needs a couple of seconds. Once the cache is set up it loads in less than half a
>>>> second.
>>> Oh nice, that functionality is part of this code? I had (incorrectly it seems)
>>> assumed the dependency checking was being done by waf.
>> The wscript uses one pickle file for the complete build specification. The
>> rtemsspec/item uses one pickle file per directory. This allows faster updates if
>> you just modify just one file of the specification.
> Could the module be exported or published from rtems-central into rtems-tools to
> it can used? Placing it into rtemstoolkit/rtemsspec/items.py to rtems-tools and
> the tool kit can use it?
Yes, but it is written in Python 3.6.