Tool chain for RTEMS 4.11

[Rempel, Cynthia]

>>>> Why not just automatically update the RTEMS-Source-Builder?
>>>>
>>> Not everyone will use the RSB, and we prefer it that way.
>> Correct.
We need developers to know how to build the tools manually so that we maintain the expertise to improve the tools source code...
>>
>> It's OK as a test bed, but it's not suiteable as a means of proper
>> system integration.
I know this sounds cheeky, but...
Proper systems integration comes from integrating systems (which is what RSB does)...
We are in the process of trying to add automated intregration testing to the RTEMS Source Builder... I'm planning on starting with a build-set to integration test gdb (as that's probably easiest, and move onto binutils next...) Right now, all we can do is run RSB and then manually do run-time simulation testing...

>Providing RPMs or any other nicely packaged binaries for a particular
>host is a nice thing to do. But each packaging format is a point solution
>for a particular OS, version, host CPU, target processor, and tool
>versions.
If we provide binary packages, they need to be tested on the host OS's and test-results submitted to gcc-testresults before we provide them for public use (systems integration :).  They need to install properly on the host no unsolvable dependencies, and they also need to be able to build all rtems executables for all rtems targets...

>It does not address a number significant number of issues:
>
>+ What about OSes which don't make the binary support list?
That's a great reason to also know how to build manually, (in addition to RSB)... what if it's not supported by RSB?
>+ What about users who need a patch that is not officially supported?
>+ What about users that want anything vaguely resembling
>    long term configuration management on their tools?
Configuration management is another part of systems integration :)
>+ What about users who need to build the libraries with specific
>     flags?
That's another great reason to also know how to build manually, (in addition to RSB)... 
>We can not and will not force RTEMS users to particular host OS
>solutions.
+1 

>There has been a concerted effort to submit all patches upstream
>in a timely manner. Queues of older patches have largely been
>cleared and we can use close to vanilla upstream source.

>You are not using the version and patches the community wants
>to use.

>If the RPMs are to have any value, then they need to be adjusted
>to match the community requirements.
Yes, the community needs to keep current, the head is where the long-term bug-fixes are...
We upstream patches promptly so we can stay current without a lot of developer overhead...
by not upstreaming patches, cross-rpms appears unable to use the current newlib...