On Sat, Oct 26, 2019 at 2:59 PM Chris Johns wrote:
>
> On 25/10/19 7:47 pm, Sebastian Huber wrote:
> > the new build system uses a set of *.ini files to configure the build. They
> > are
> > stored in the build lock file:
> >
> > build/.lock-waf_linux2_build:options = {..., 'rtems_options': 'bsps
On 25/10/19 7:47 pm, Sebastian Huber wrote:
> the new build system uses a set of *.ini files to configure the build. They
> are
> stored in the build lock file:
>
> build/.lock-waf_linux2_build:options = {..., 'rtems_options': 'bsps.ini', ...}
>
> I would like to issue a re-configuration if one
On 26/10/19 6:57 pm, Thomas Doerfler wrote:
> Joel,
>
> it all comes down to "where was it tested". Knowing a certain test works
> on ONE architecture, on ONE member of a BSP family never means it works
> on all. Surely if it fails on one member it makes other members's
> support suspicious, but t
Hi
I have been trying to build up a script which tests as much as possible. I
have had enough script and tool build issues to not look at results much.
But this will need attention and help:
https://lists.rtems.org/pipermail/build/2019-October/007654.html
The gdb arm sim bsp has outlived its use
Joel,
it all comes down to "where was it tested". Knowing a certain test works
on ONE architecture, on ONE member of a BSP family never means it works
on all. Surely if it fails on one member it makes other members's
support suspicious, but the result is always for the hardware/simulator
it ran on
