Separation of RTEMS sources and tool chain patches

[Chris Johns]

On 30/09/2014 6:40 pm, Sebastian Huber wrote:
> On 29/09/14 08:15, Chris Johns wrote:
>>>
>>> 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.
>>>
>>
>> I am ok with the INI file that defines the tools for a release being
>> held in
>> RTEMS and the build system checking the tools however at this point in
>> time I
>> do not think is it a good idea to move everything into RTEMS. I have
>> not given
>> the idea much consideration but I see issues with the validation
>> process. For
>> example the tools and RTEMS can move independently of each other and
>> on head
>> this is a little more difficult however with a release things are much
>> more
>> stable. This means a dot point release of RTEMS does not require a dot
>> point
>> version of tools.
>>
>> My view may change as what we have moved too settles and maybe I am just
>> hesitant to move too quickly here.
>
> In case you have an RTEMS release and then a tool chain patch change is
> necessary, can't you simply do this update in the RTEMS release branch?
> You need a branch update anyway to bring in the new INI/XML file
> describing the current tool chain intended for this RTEMS version.
>

Yes this is correct and an XML/INI file in rtems is something I support. 
It defines the project's supported and tested tool set. The definition 
file(s) should be positioned out front in the top level directory.

It is the patches in the rtems source tree and having RTEMS build the 
tools I am not as sure about.

The tools are a table of architecture vs source and patches for each 
tool component. These tables are large and what is used varies. If we 
move to tool patches in the RTEMS source tree a number of issues appear. 
Take the openrisc support. It is currently based on a specific non-FSF 
version of gcc as the openrisc project merges its support upstream into 
the FSF repo. The RSB allows this and I support it happening because it 
has allowed RTEMS to get support added and a successful GSoC project to 
happen this year plus I am confident the openrisc project will complete 
the merge. Does having the tool patches in rtems require we take the FSF 
code those tools are based on, create a diff and add it to RTEMS or do 
we create exceptions to the rule ?

There is also a dependence issues between the RSB and RTEMS. At the 
moment you can get a copy of the RSB and build the tools and RTEMS 
(--with-rtems). I often get emails related to 4.10 so this is used by 
users for the previous release of RTEMS. On the other hand I like the 
idea of getting the RTEMS source and configuring to say I want a 
sparc/sis BSP and then having RTEMS build a set of tools and then the 
BSP. These are 2 different use cases. The RSB leading the way is an 
architecture tool set for a number of BSPs and an RTEMS internally built 
tool set specific to a BSP or group of BSPs.

Finally Windows tools are not able to be built from source on Windows. 
Performance issues aside the msys and cygwin support plus recent make 
bugs have limited the success. It is possible to get a thin script to 
build a tool set from source however this has proven more difficult with 
the RSB for a number of reasons some of which are listed in the RSB doco 
under the Windows section.

Chris