On 15/10/20 5:43 pm, Sebastian Huber wrote: > On 15/10/2020 08:41, Chris Johns wrote: > >> 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? > Yes, waf works with Python 2 and 3.
... and it can load the spec files? Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
