Re: [SOLVED] Re: Further problems trying to build GNUstep with blocks/properties support

[Richard Frith-Macdonald]

On 22 Jun 2010, at 11:28, Thomas Davie wrote:

> 
> On 22 Jun 2010, at 11:19, Richard Frith-Macdonald wrote:
> 
>> 
>> On 22 Jun 2010, at 10:56, David Chisnall wrote:
>> 
>>> On 22 Jun 2010, at 10:51, Thomas Davie wrote:
>>> 
>>>> The only problem I have remaining is that it appears that nowhere in 
>>>> Foundation.h is blocks_runtime.h ever imported.  The result is that in my 
>>>> code, Block_copy and friends are inaccessible.  I don't know where the 
>>>> appropriate place to include this is, could you add it in the right place 
>>>> and commit again?
>>> 
>>> Richard, I think this one's for you...
>>> 
>>> We only need to bother including blocks_runtime.h when using clang, since 
>>> GCC doesn't support blocks, so we can wrap it in a __has_include() test, 
>>> but we should probably also wrap it in a __has_feature() test to make sure 
>>> we are compiling with -fblocks (I'm not sure what happens if you include 
>>> that header without blocks support).
>>> 
>>> How are we currently deciding whether to import the libobjc2 or ObjectiveC2 
>>> headers in Foundation?  I've not really checked, but we should be doing 
>>> this the same way...
>> 
>> There's a configure-time check to see which runtime is in use, then we 
>> include the appropriate headers depending on the saved results of that check.
>> 
>> I've modified GSVersionMacros.h to include the blocks runtime header the 
>> same way (if the current compiler has the blocks feature).  I'm not 
>> completely sure this is the best place to do it, but it ensures that the 
>> blocks stuff is always available.
>> 
>> Though, since i've no code using blocks, I've not actually tested this.
> 
> There's a slight problem with this approach – previously, it was possible to 
> compile gnustep-base with gcc, and expect blocks code to work if your binary 
> was compiled with clang, this is no longer the case, as blocks_runtime.h will 
> never be included.  This kinda loops back on my original issue that clang 
> bails/hangs trying to compile GSFormat.m.

I may be misunderstanding, but that seems OK to me:
1. you build base using gcc ... the blocks runtime header is not included at 
this point, but that's OK since base doesn't use blocks.
2. you build your code with clang ... the blocks runtime header *is* included 
... your code is able to use blocks.

Incidentally, my copy of clang builds GSFormat.m without complaint/problem.

$ clang --version
clang version 2.0 (trunk 105381)
Target: i386-pc-linux-gnu
Thread model: posix