Compiling the RTEMS HEAD

[Ralf Corsepius]

On 01/28/2011 01:52 AM, Chris Johns wrote:
> 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 ?
This question is formulated in a way it's close to impossible to answer :)

In general, yes, a project needs to _define_ "a lowest common 
denominator platform" for its code. What this lowest common denominator 
is, is widely scalable.

> If so what is this ?
>
Well, the issue this thread has started with, is code fails to compile 
on a platform it wasn't designed to used on and it being used for a 
use-case it wasn't designed for.

I.e. in my view, this question is 3-fold:
- Is this a legitimate design or a poorly designed case of code abuse? 
In my personal opinion, the latter applies.
- the impact schedsim has on RTEMS code-base.
- the portability issues it suffers from.

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

> 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.
My view differs: I consider schedsim to be a design, without any future. 
I am well aware this won't taste some people, but this had to be said.

> What if we only built it if enabled and the host compiler supports the 
> RTEMS C standard it currently supports ?
Well, checking for "standards" doesn't work (Whose standard? Which 
standard? Whose interpretation of a standard?). The classic autoconf 
approach (Check for features, try to gracefully degrade if possible and  
bomb out it not) could be made workable, however.

The fundamental question to me however is: Is it worth it?
... no user-base, no applications, questionable design, build-tree 
bloat, ...?

Ralf