Fwd: [rtems-bsp-builder] 2020-10-13 09:15:22: Profile(s): everything
chrisj at rtems.org
Wed Oct 14 22:48:01 UTC 2020
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>>
> 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.
More information about the devel