Compiling the RTEMS HEAD

[Chris Johns]

On 26/01/11 6:52 PM, Ralf Corsepius wrote:
>
> In other words, in general, the only way to escape this is to write
> portable code and/or to apply configure-checks to cope with changing
> standards and different levels of standard-compliance.
>

Does this mean we should support the lowest common denominator for host 
built code ? If so what is this ?

> Also note that wrt. RTEMS itself, we escape a lot of the nastiness
> lurking inside by "tying" specific RTEMS releases to specific
> GNU-toolchain releases. The breakdown this thread started with clearly
> exposes this.

RTEMS should be allowed to look forward with regards to standards and be 
not required to conform to old standards that may be in use on some host 
for unrelated reason.

I agree schedsim breaks this which is an issue. I feel schedsim should 
be disabled by default because only a small set of RTEMS users will ever 
use it and only then for specific cases. What if we only built it if 
enabled and the host compiler supports the RTEMS C standard it currently 
supports ? If the host does not support the required standard it is not 
built.

Chris