Separation of RTEMS sources and tool chain patches

[Sebastian Huber]

On 18/09/14 00:58, Chris Johns wrote:
> 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.

This is really nice.  I think the default output is even better since it 
includes also the shell scripts for the tool builds.  Maybe we should add also 
some sort of XML output since this is easier to parse.

>> 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.

The RSB uses the rtems-tools repository to get some patches.  Uses it always 
the latest versions or a particular commit?

Why do we not move the tool chain patches back to the RTEMS sources?  I think 
it would be nice if you can check out a particular RTEMS version and then use 
the RSB and say: build me the tool chain for this version.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.