change log for rtems (2010-06-24)

[Chris Johns]

On 25/06/10 5:35 PM, Ralf Corsepius wrote:
> On 06/25/2010 09:19 AM, Chris Johns wrote:
>> On 25/06/10 5:10 PM, Ralf Corsepius wrote:
>>>>>
>>>> I don't think that this explosion of ifdef is good.
>>>
>>> ACK.
>>>> Why not add a
>>>> rtems_assert() which is defined in case of RTEMS_DEBUG?
>>>>
>>> Why? Haven't you guys heard about NDEBUG?
>>>
>>> All these defines are superfluous.
>>>
>>
>> The only issue with NDEBUG is the interaction with an application. If
>> a user uses NDEBUG in an application what happens to RTEMS includes
>> etc if RTEMS is not built with NDEBUG ?
> You are outsmarting yourself.

I wish I was that clever.

> * newlib and the gcclibs all are built without NDEBUG.
> * compiling RTEMS with -DNDEBUG is a micro-optimization only affecting
> RTEMS

If that is how developers use it and we control it. My concern is a 
struct needs to depend on NDEBUG to work and the application then uses 
NDEBUG.

> * assert.h is guaranteed to be present. Conditionally including assert.h
> doesn't buy you anything.

Sure. I agree with this.

>> A single common method in RTEMS would be nice and I do not care much
>> what it is. All I ask is it being controlled by configure's
>> --enable-debug.
> --enable-debug is supposed to enable some internal debug aids. It is not
> supposed to interact with NDEBUG.

I was not suggesting it should and that in my mind rules NDEBUG out for 
me. I am thinking RTEMS should consider our own version to avoid clashes 
or problems with users.

Chris