Compiling the RTEMS HEAD

[Chris Johns]

On 28/01/11 1:50 PM, Ralf Corsepius wrote:
> 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.
>

Windows 95 ? ;)

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

There must be no impact on the RTEM code-base in terms of design or 
coding levels. If the tool cannot use RTEMS code as is then it needs to 
change or the approach evolve to something else.

RTEMS development cannot be forced to consider an outside package when 
being developed. By its nature the schedsim tool will break over time 
and the maintainers and users need to agree they will monitor this and 
fix it. On the other side its users can build better ways for RTEMS to 
run with out the complexity of obtaining a proof in a real system. This 
of course means the tool has a means of validating itself against a real 
target run.

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

You may be proved correct over time but it is difficult for any piece of 
open source software to gain traction without easy access to possible users.

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

I was thinking about some simple tests and if they fail to not build. 
For example gnu99.

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

If we can attract research in real time schedule design then it could 
be. We cannot do this unless we provide something to help.

Chris