On 27 Feb 2011, at 08:35, Fred Kiefer wrote: > > -------- Original-Nachricht -------- >> Datum: Sun, 27 Feb 2011 01:20:58 +0000 >> Von: David Chisnall <[email protected]> >> An: Fred Kiefer <[email protected]> >> CC: GNUstep Developer <[email protected]> >> 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. _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
