Re: [Gnustep-cvs] r32376 - in /libs/base/trunk/Source: GNUmakefile GSBlocks.m

[Richard Frith-Macdonald]

On 27 Feb 2011, at 08:35, Fred Kiefer wrote:

> 
> -------- Original-Nachricht --------
>> Datum: Sun, 27 Feb 2011 01:20:58 +0000
>> Von: David Chisnall <address@hidden>
>> An: Fred Kiefer <address@hidden>
>> CC: GNUstep Developer <address@hidden>
>> Betreff: Re: [Gnustep-cvs] r32376 - in /libs/base/trunk/Source: GNUmakefile  
>> GSBlocks.m
> 
>> On 26 Feb 2011, at 20:40, Fred Kiefer wrote:
>> 
>>> Now you did the fixes that I listed as the easy ones. You still didn't
>>> add a proper heading for the file. Nor did you write a solution for
>>> stupid linkers. Your idea of using #if __has_feature(blocks) should
>>> work, but somebody has to put it in there.
>> 
>> Ah, I see what you mean.  The issue is not the compiler having blocks
>> support, it's the blocks runtime existing.  That shouldn't be a problem,
>> because we provide a blocks runtime as part of the ObjectiveC2 framework, so
>> there shouldn't be any cases when those functions don't exist - they will
>> either be provided by libobjc2, or by -base.

That's not really the case ... since the ObjectiveC2 framework is only built 
for older compilers.  I guess this file needs to implement the blocks stuff 
itsself when required.

> Great, I did not know that. Sorry for this mail than.

The point about the file header still remains.

There was also an issue of other coding standards ... but I did a quick edit to 
make the indentation/whitespace usage more readable.

But ... another issue is breaking things ... at a bare minimum we should try 
not to have commits stop the libraries from compiling or break existing code.  
And by that I mean that the major platforms should not be broken.

That means primarily that changes should compile and not break the testsuite 
when tested with a mature version of gcc and the gnu runtime on a gnu/linux 
platform.

It is NOT sufficient to test changes with an unusual compiler (eg clang or very 
recent gcc) or to test them with an unusual runtime, or to test them on an 
unusual operating system... if you use some unusual combination it's all too 
easy to break things for the vast majority of people.

Ideally, we would test things on multiple systems before committing, but that's 
hard to manage.  I find it generally works best to test and commit on a 
mainstream platform, then immediately checkout  the changes on to a couple of 
other platforms and build/test there so that, if a change is OK for most people 
we also find out very quickly if it's not OK on less common systems.

So, my recommendation (which I confess I haven't always followed) is that you 
have a single mainstream system where gnustep is checked out with write 
permission, and for the less common platforms you check out a read-only copy of 
the code.  That way it's much harder to accidentally commit changes which you 
tested on the wrong platform.