Release?

[Chris Johns]

Rempel, Cynthia wrote:
>> On Mon, Jul 15, 2013 at 1:37 PM, Rempel, Cynthia
>> <cynt6007 at vandals.uidaho.edu>  wrote:
>>> 3. We have some sort of linking and running criteria for rtems toolchains without rtems kernels, or we don't have rtems toolchains for rtems kernels
>> Can you explain this #3? I don't quite get it.
> Users use toolchains built with (i.e. xxx-rtems4.11-gcc), but they don't use the rtems kernel for their "bare metal" embedded work... don't know why...

The reason I know of for non-rtems-kernel compiles and links is related 
to configure type tests. The configure process may run a compile and 
link to check if a symbol is in a library. It is not the typical use 
case for an RTEMS user. Having said this u-boot and other boot monitors 
may use the RTEMS tool sets to build themselves. I have a recent u-boot 
for the ARM based Zynq device building with a recent RSB RTEMS ARM tool set.

> but if we support users of these toolchains we should test the toolchains...

Yes we should. I do not think we are in a position to automatically 
manage this however I do think someone needs to walk a tool chain build 
through the gcc testsuite. I am happy to help support someone doing this 
with the RSB tool chain for archs that support it. We just need to 
settle on the specific tool set configuration for 4.11. The RSB is now 
using newlib 14-Jul-2013 and Sebastian's cxa_atexit and PPC SDATA patch. 
The pthread.h newlib header issue is currently unresolved.

FYI I have the RSB automatically building autoconf and automake from 
source so those users on hosts that do not have recent autoconf and 
automake packages should not see the annoying wrong autoconf error 
message when RTEMS is being built after the compiler has been built.

>>> 6. (Process) we have a build-bot script running that checks (and rejects) each rtems patch for compile / link errors (that checks every BSP)
>>> 7. (Process) we have a script that builds and tests the trunk of binutils, gcc, newlib, gdb which in turn builds all the rtems tests (referenced against the rtems trunk revision as of the time of the gcc release) and posts the results to gcc-testresults (as binutils, newlib, and gdb don't have a test results email).
>> These #6 and 7 will have to wait, but they are not specificaly
>> release-related. At the least, 6 won't be feasible until after we
>> release 4.11.
> That sucks that we're stuck manually checking each patch...
>
> FWIW, there will most likely be pressure to add features up until the release... in which case, what will probably happen is a "feature freeze" -- which will be unpopular and lead to "coding opportunity loss" -- and we'll be putting out a release that doesn't compile/link on some targets...

Yeah it is not optimal but this is what we have. Building rtems with 
buildbot using the current build system is not practical and changing 
the build system for 4.11 is also not practical. The overriding need is 
for 4.11 to be released.

> Although at one point I was able to build the toolsets using the RSB (before it built the kernel) on gcc-20, and it successfully found the targets with the errors, it might be as simple as to take such a script and use the number of lines of compiler errors to determine if there is a problem with the patch...  (It could be a git script)

I suspect we will need to manage this manually for 4.11. If we have the 
computing resources available maybe a branch specific git script could 
be used. Currently we do not have the resources. I should point out the 
m68k build of all BSPs is a massive disk user. I suspect an objcopy to a 
binary target specific file is picking up some massive address offset 
creating gigabyte images.

We also need to understand building all BSPS results in over 1200 header 
files per BSP being preinstall and we now have over 140 BSPs so the 
number of header files installed has reach a critical and silly level 
given the 1200 or so original files are sitting in the cloned git repo. 
This is a topic for post 4.11 and maybe RTEMS 5.0.

> (Of course, we could avoid this problem by using a script to:
> a. build rtems on all targets -- RSB is very useful for this,
> b. put the output into a file,
> c. filter the output file for compiler and linker errors into another file
> d. if the number of lines in the filtered file exceeds a specified number -- reject the patch)
> This of couse won't catch all the errors, but likely many of them...
>
> But if hooking such a script into git isn't feasible, it's not... that sucks.

See above, and yeah I agree it sucks.

Chris