Separation of RTEMS sources and tool chain patches

[Chris Johns]

On 17/09/2014 6:49 pm, Sebastian Huber wrote:
>
> currently the RTEMS sources contain no reference to the intended tool
> chain versions (Binutils, Newlib, GCC, GDB) and patches for the tools.
> This is specified elsewhere, for example in the RTEMS tools repository.
>

The RSB has the ability to report its configuration as an INI file. If you:

  $ cd rtems-source-builder/rtems
  $ ../source-builder/sb-reports --format=ini 4.11/rtems-all

you will get a '4.11-rtems-all.ini' file. It contains the exact source 
configuration including the MD5 hashes for all the architectures and is 
human readable.

Just looking at the output now I see I did not place the RSB git hash in 
a section and I think it should be. It is in a comment. I will make the 
change. If you have the git hash you can request that specific RSB 
version and so build those tools.

> Since the RTEMS version is tightly coupled to a particular tool chain
> version (mostly do to interaction with Newlib) it would be beneficial to
> add a human and machine readable tool chain description to the RTEMS
> sources (for example base version plus patches).  One consumer of this
> description could be the RSB.  This would enable automatic builds of a
> compatible tool chain as part of a Git bisect process to find changes
> causing a regression.

This is a nice idea and I fully support us doing this. There are a 
couple of assumptions that need to be handled.

The first is a mutual dependence between the tools and RTEMS so someone 
needs to build the tools and then build RTEMS then take the INI file and 
add it to RTEMS so in effect tagging the RTEMS version with the tools.

The second assumption is the build hosts are not moving too fast. There 
will be a historical limit to which we can regression test based on the 
specific host's ability to build older tool sets. For example breakage 
tends to happens when a host picks up a new version of a compiler that 
moves the default standard supported.

Doing this means a user should be able to get an RTEMS source tree and 
run a top level command that builds the tools and then RTEMS. I like 
this because it is logical for a user to do and removes a major step 
that has proved to be error prone and problematic for new users.

The RSB built tools embed the RSB hash in the GCC version string so the 
RTEMS build system could verify the tools match if not in maintainer mode.

Chris