BSP Build Sweep Report (5 Oct)

[Joel Sherrill]

On Mon, Oct 5, 2020 at 8:36 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 05/10/2020 15:30, Joel Sherrill wrote:
>
> >
> >
> > On Mon, Oct 5, 2020 at 8:05 AM Sebastian Huber
> > <sebastian.huber at embedded-brains.de
> > <mailto:sebastian.huber at embedded-brains.de>> wrote:
> >
> >     On 05/10/2020 14:56, Joel Sherrill wrote:
> >
> >     > Hi
> >     >
> >     > The build sweep completed overnight and there were a lot of BSPs
> >     which
> >     > did not build to completion. This is the summary:
> >     >
> >     > BSPs:    192
> >     > Total:   1745 all-bsps-log.txt
> >     > Passed:  1532
> >     > Failed:  212
> >     >
> >     > Failed autoconf:  178
> >     > Failed waf:       34
> >     > Failed (NOSMP):   78
> >     >
> >     > The full summary with one line results per build is attached.
> >     >
> >     > A breakdown per architecture is:
> >     >
> >     >      66 arm
> >     >      12 powerpc
> >     >     114 riscv
> >     >      16 sparc
> >     >       4 x86_64
> >     >
> >     > Execution time of the entire sweep on an 8 core Xeon. This is a
> >     mix of
> >     > autoconf, waf, and scripting:
> >     >
> >     > 356304.80user 89111.84system 41:43:26elapsed 296%CPU
> >     > (0avgtext+0avgdata 184740maxresident)k
> >     > 6859544inputs+3400037288outputs
> >     (6432major+33833619401minor)pagefaults
> >     > 0swaps
> >     >
> >     > It looks like there is a lot to resolve before the switchover
> >     can occur.
> >     I am not sure if it is really worth to fix the Autoconf/Automake
> >     issues.
> >     We have RTEMS 5 for a comparison. The real issues in the build are
> >     exposed when you run the tests. The linker command files, custom
> >     start
> >     files, boot loader support, and BSP options are the things which are
> >     likely broken.
> >
> >
> > I think a lot of those were testopts.h which you fixed. Thanks.
> >
> > No matter what you think of autoconf, there are 34 waf builds failing.
> > I haven't been through the log to see if those all fail with autoconf but
> > verifying 34 configurations fail in the same way on the two build systems
> > is too much to do IMO. Better to fix the underlying issue and get close
> to
> > zero build failures.
> >
> > I'm willing to accept some failures but I also think you can't wave your
> > hands and say it doesn't matter. We will switch to waf but the results
> > will be much much closer before I agree. I will eventually be doing a
> > similar build of 5 because I wasn't making this kind of sweep until
> > starting
> > to look at waf v autoconf.
>
> I am not arguing over the waf failures. I think build runs with
> RTEMS_DEBUG enabled surfaced some issues. I didn't build with this
> option so far, but I will do an overnight run with this option.
>

I just started another sweep since testopts.h is likely the cause of most
of the autoconf failures.

>
> I am not sure if it is worth the trouble to fix the Autoconf/Automake
> test states for RTEMS 6.
>

Adding one line to a tcfg vs tracking why the builds are different. I
see fixing these as a no-brainer. Harder issues are another question.

--joel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201005/3a0857d4/attachment-0001.html>