GCC Version Questions

[Thomas Doerfler]

Chris,

Am 29.04.2012 03:52, schrieb Chris Johns:
> On 28/04/12 6:18 PM, Thomas Doerfler wrote:
>> Hi,
>>
>> Am 28.04.2012 05:57, schrieb Ralf Corsepius:
>>> On 04/27/2012 04:00 PM, Sebastian Huber wrote:
>>>> I would rather use GCC 4.6.X for the RTEMS 4.11 release on ARM since I
>>>> had a lot of trouble with earlier version of GCC 4.6. I worked with GCC
>>>> 4.6 during the whole 4.11 development cycle and I am really at
>>>> unease to
>>>> use an untested GCC 4.7 for this release.
>>>
>>> Sebastian,
>>>
>>> a) rtems4.11 is the unstable, rolling development branch, which may eat
>>> the hair of your head and may eat your family and children.
>>> It's _you_ (The developers) who are testing and are supposed to find,
>>> report and occasionally fix the bugs.
>>
>> Sebastian, maybe it makes sense to give gcc-4.7 a try. we have not yet
>> branched off towards a 4.11 release, so Ralfs view seems reasonable to
>> me.
> 
> Thomas, I do not fully agree. The HEAD is the place for new development
> and not suitable for production. Features and changes should be added
> once they are stable, complete and tested. If you are working on changes
> that can break others use your personal repo or a private repo until you
> have stability. It is the developer's responsibility to track head and

In general this makes sense. But due to the many architectures and
targets supported by RTEMS and due to the limited automated test
capabilities nobody is able to test a certain change in RTEMS code or
tools for every target.

You can check, whether RTEMS can still be built for every supported
targetafter a code patch a or toolset change, but that doesn't ensure,
that the system is still functional.

IMHO, a possible development process would look like this:

a) take HEAD of git-master as a starting point
b) change RTEMS or toolset codecode or toolset
c) test it to execute the test suite for all targets
d) resync git with HEAD
e) test it to execute the test suite for all targets
f) apply patch back to git-master

Unfortunately we have no standard procedure to execute steps c) or e).
Most of us have access to some targets. We _might_ use the simulators as
far as possible, but they only cover a subset of targets and architectures.

So up to now everyone depends on "distributed testing", in parallel to
the rtems-master HEAD development.

It would be great to have a fast enough build system and an automated
test bench that permanently gives feedback about the abilities to build
and properly execute the test bench on all architectures and as many
targets as possible. ;-)

> merge in changes while they work on new features. There is nothing
> unusual in this, just common sense. I see no reason to treat the tools
> any differently. The tool are pushed out with no staging, testing,
> method of review and often no announcement. The patches used to build
> the tools are jumbo and it is difficult to find the relationship to a
> patch and documented fix in the upstream project. I have never seen any
> test reports for the tools in the yum repo.

We should cover this, maybe with a general test bench.

> RTEMS is about the RTEMS code base and not a means to trial and test
> tools. It is good engineering practice to vary only one thing at a time
> and not to have 2 parts varying. Currently if you are adding new
> features to the RTEMS code base you also have the adding uncertainty of
> the state of the tools. As the recent bintutils powerpc bug has shown it
> seems the developers attempting to work on RTEMS need to clean up and
> fix tool issues in order to do the work on the RTEMS code.

I see your point but have a slightly different view to it. Anyway we
might need to adapt the way the toolsets are generated and maintained.

During RTEMS code development, you may see patches on git that were
developed in parallal to your own area of work, so at least when you
sync back to git-master, you may find new patches/functionaliy.

The toolset upgrades are quite similar: If you regard them like a patch
that has come up, you see many similarities.

Things that may be different:
- I am not sure how you can keep multiple toolsets on the same machine
and switch between them. This would be of great help.

> 
> I see us needing stable and experimental tool chains on head and release
> branches. When a tool chain has suitable test reports from the gcc test
> suite and the RTEMS test suite for the effected architectures the
> project should be consulted about moving that specific tool set to stable.

ACK.

Thomas.
-- 
--------------------------------------------
Embedded Brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18908079-2
Fax:   +49-89-18908079-9