On Oct 29, 2019, at 15:43, David Chisnall wrote:
> On 29/10/2019 13:18, Ivan Vučica wrote:
>> Naive question: What’s the problem #ifdefing out the code that depends on
>> blocks when building on gcc?
>
> Locally? Not much. It means that anyone using clang and a GCC-built GNUstep
> will
Naive question: What’s the problem #ifdefing out the code that depends on
blocks when building on gcc?
On Tue 29 Oct 2019 at 12:51, David Chisnall
wrote:
> On 27/10/2019 16:05, Gregory Casamento wrote:
> > We are a GNU / FSF project. Dropping support for GCC would be bad
> > political mojo.
On 27/10/2019 16:05, Gregory Casamento wrote:
We are a GNU / FSF project. Dropping support for GCC would be bad
political mojo. There is little we can do to bridge the gap other than
doing these macros.
I don't really understand how this works. GCC does not support a
post-2005 dialect of
This is not possible in the general case.
A block is a structure containing:
- A pointer to the invoke function.
- The type info for the call.
- A set of references to captured variables including:
- Helpers to destroy any captured variables.
- Helpers to copy any captured variables.
Yes, it appears a few bogus commits have ended up on trunk tonight. :-(
> Am 29.10.2019 um 09:17 schrieb Riccardo Mottola :
>
> Hi,
>
> if I compile base, I get this error:
>
> Compiling file NSMetadata.m ...
> In file included from NSMetadata.m:35:
> ../Headers/Foundation/NSMetadata.h:33:9:
Hi,
if I compile base, I get this error:
Compiling file NSMetadata.m ...
In file included from NSMetadata.m:35:
../Headers/Foundation/NSMetadata.h:33:9: fatal error:
Foundation/NSMetadataAttributes.h: No such file or directory
33 | #import
|
