Hi Mark, On Tue, Mar 13, 2012 at 11:46:39PM -0400, Mark Heily wrote:
While I am glad to hear you are working on getting blocks support added to GNUstep, I am not sure it makes sense to have a completely different blocks runtime for Objective-C v.s. ordinary C. Judging by the headers in libobjc2, it looks like you reimplemented the blocks runtime rather than copying it verbatim from compiler-rt. That has me somewhat worried about possible differences and incompatibilities, and I would prefer to use the "official" blocks runtime if possible.
First of all: We don't expect people to use different runtimes for C and Objective-C programmes. C programmes will work just fine with libobjc2 as the blocks runtime (without the need to link the Objective-C Foundation library and all), as libdispatch clearly demonstrates. Furthermore, I don't think that GNUstep having its own implementation of the blocks runtime is a real issue. After all, both the compiler-rt blocks runtime and the GNUstep one work with blocks generated by clang. Also, if incompatibilities did arise (which I think they won't), we could always have a look at the specification and decide who get things wrong ;-)
As an alternative, I have repackaged the blocks runtime found in compiler-rt, and made a standalone library named libBlocksRuntime [1]. This is currently used for C/C++ programs that use libdispatch, and I would hope that Objective-C programs could also link against this library.
Well, the problem is that Blocks are first class objects in Objective-C. The compiler-rt blocks runtime has some shims for this that the Foundation library is required to patch up afterwards. By having blocks support directly in the runtime, we avoid these troubles. I hope this clears a few things up. I've also CCed David Chisnall, the maintainer of the GNUstep Objective-C runtime, who might have some more insights into this. Cheers, Niels