[libdispatch-dev] [PATCH 05/17] more precise detection of blocks

Kevin Van Vechten kvv at apple.com
Mon Oct 19 00:10:15 PDT 2009

On Oct 18, 2009, at 12:25 PM, Jordan K. Hubbard wrote:

> On Oct 18, 2009, at 8:04 AM, Paolo Bonzini wrote:
>> I now make the test a bit more precise; for some reason my first LLVM
>> installation had blocks but no Blocks.h and Blocks_private.h.  After
>> adding this check, using __BLOCKS__ is not sufficient anymore hence
>> I changed it all over the place to an autoconfy HAVE_BLOCKS symbol.
> I think your llvm/clang installation is missing the appropriate compiler_rt bits.  You should definitely have a Blocks.h and Blocks_private.h as part of being a platform which supports Blocks.  That said, if your autoconf-driven HAVE_BLOCKS check is more robust in the face of incomplete installations then it sounds like a win regardless, just so long as we are clear on what a "correct" clang install looks like. :)
> So.  On all !MacOSX systems, I'm assuming it's now also the default assumption that "Blocks support" means "Clang + LLVM + compiler_rt"?  I haven't heard much, if anything, about anyone pursuing the gcc alternative.

Unfortunately testing for HAVE_BLOCKS will be problematic in the libdispatch public headers as they need to be parsed by client projects which will not include the libdispatch config.h.  That said, it should be fine to test for HAVE_BLOCKS in the libdispatch implementation (which is where the real compiler_rt dependency is anyway).


More information about the libdispatch-dev mailing list