On 15/10/20 5:34 pm, Sebastian Huber wrote: > 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.hu...@embedded-brains.de >>>>>>>>> <mailto:sebastian.hu...@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.hu...@embedded-brains.de >>>>>>>>> <mailto:sebastian.hu...@embedded-brains.de> >>>>>>>>> > <mailto:sebastian.hu...@embedded-brains.de >>>>>>>>> <mailto:sebastian.hu...@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.
Ah ... but waf is python 2 and 3? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
