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