Compiling the RTEMS HEAD

[Ralf Corsepius]

On 01/28/2011 07:43 AM, Chris Johns wrote:
> 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 ? ;)
Yes. combined with Turbo-C, this would make a nice candidate.

I'd personaly favor VMS+VAX-C87 - The worst platform, I ever had to use 
(pre-c89 ANSI C with incomplete and often broken libc).

>
>>> 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.
This code pokes deep into the RTEMS source tree ...

> If the tool cannot use RTEMS code as is then it needs to change or the 
> approach evolve to something else.
IMO, the approach is flawed from it's lowest fundations upward. To me, 
it's essentially a brute force attempt to revive what was once the 
posix/linux BSP, but without the overhead and without proper integration 
(the posix/linux BSP wasn't properly integrated either, but schedsim 
seems beyond reason to me).


>>> 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.
Well, the problem with this is: What to test for and how?

I mean, we can try to check for "is the compiler GCC and accepts 
--std=gnu99 then set CC_FOR_HOST=gcc --std=gnu99", and "bomb out" otherwise.
This will help in many occasions, but in others it won't, because each 
gcc release and each vendor-gcc has a different 
understanding/interpretation of --std=gnu99.

In other words, --std=gnu99 would be an initial step to hide away most 
breakdowns from users (Setting CC_FOR_HOST="gcc --std=gnu99", schedsim 
compiles under CentOS5.), but there is much more to do (As anybody tried 
to build schedsim on MacOSX, Solaris, MinGW or Cygwin using their 
native, vendor-supplied compilers or icc on Linux?)

>
>> 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.
But we can try avoiding wasting resources and time;)

Ralf