[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [SOLVED] Re: Further problems trying to build GNUstep with blocks/pr
From: |
Thomas Davie |
Subject: |
Re: [SOLVED] Re: Further problems trying to build GNUstep with blocks/properties support |
Date: |
Tue, 22 Jun 2010 11:28:41 +0100 |
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.
Thanks
Tom Davie
- Re: Further problems trying to build GNUstep with blocks/properties support, (continued)
- Re: Further problems trying to build GNUstep with blocks/properties support, Thomas Davie, 2010/06/21
- [SOLVED] Re: Further problems trying to build GNUstep with blocks/properties support, Thomas Davie, 2010/06/21
- Re: [SOLVED] Re: Further problems trying to build GNUstep with blocks/properties support, David Chisnall, 2010/06/21
- Re: [SOLVED] Re: Further problems trying to build GNUstep with blocks/properties support, Thomas Davie, 2010/06/22
- Re: [SOLVED] Re: Further problems trying to build GNUstep with blocks/properties support, David Chisnall, 2010/06/22
- Re: [SOLVED] Re: Further problems trying to build GNUstep with blocks/properties support, Thomas Davie, 2010/06/22
- Re: [SOLVED] Re: Further problems trying to build GNUstep with blocks/properties support, David Chisnall, 2010/06/22
- Re: [SOLVED] Re: Further problems trying to build GNUstep with blocks/properties support, Thomas Davie, 2010/06/22
- Re: [SOLVED] Re: Further problems trying to build GNUstep with blocks/properties support, David Chisnall, 2010/06/22
- Re: [SOLVED] Re: Further problems trying to build GNUstep with blocks/properties support, Richard Frith-Macdonald, 2010/06/22
- Re: [SOLVED] Re: Further problems trying to build GNUstep with blocks/properties support,
Thomas Davie <=
- Re: [SOLVED] Re: Further problems trying to build GNUstep with blocks/properties support, Richard Frith-Macdonald, 2010/06/22
- Re: [SOLVED] Re: Further problems trying to build GNUstep with blocks/properties support, Thomas Davie, 2010/06/22