HI Luboš, Am 04.02.2014 um 10:29 schrieb Luboš Doležel <lu...@dolezel.info>:
> You're right, libdispatch would be great for this. But what I fear is that as > soon as I start working in that direction, someone will come and either start > complaining about a libdispatch dependency or Clang requirement once I dare > to use a block. And the last thing I would do is to write one worse > implementation for GCC and one nice implementation for Clang. The ability to invoke blocks doesn’t really commit you to using clang (-base has support code to invoke blocks when compiled with GCC) you only need it when you want to create blocks (does CFRunLoop need to do that? I think it might not…). So the question is rather whether we could rely on a compatible libBlocksRuntime being reasonably widespread (libdispatch usually isn’t the issue, but you need the version libBlocksRuntime that exports is symbols weakly so that libobjc2 can override them). In other words: I don’t think backwards-compatibility is as important for corebase as it is for -base. I have one comment about the ‘weakly-load-NSCFRunLoop-if-corebase-is-also-linked’ thing: I think it’s a good idea in general, but how would we handle cases where you start up without corebase, and during runtime you load a bundle that is linked against it? That might be a bit tricky to get right… Cheers, Niels PS: Thanks a lot for working on corebase! I especially like having the CFStream stuff available... _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
