gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Embedded blocks...


From: Ivan Vučica
Subject: Re: Embedded blocks...
Date: Tue, 29 Oct 2019 13:18:58 +0000

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 <address@hidden> 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.   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 Objective-C.  GNUstep is a framework that aims to
provide an implementation of the 2019 Objective-C standard library.  Why
is it politically problematic for GNUstep to drop support for GCC, but
not problematic for GCC to drop support for GNUstep?

For what it's worth, I've spoken to a couple of GCC devs over the last
few years about supporting modern Objective-C (because I would like us
to have a choice of compilers), but the effort involved for them is huge
(even a naive ARC implementation is a big piece of effort) and the
return is small (why would anyone use it?  Basically, the only target
market is GNUstep developers on platforms that Clang doesn't support,
which I think is a set containing only Riccardo).  There is some
interest in supporting blocks, because Apple's libc headers no longer
support compilers that don't support blocks, but even then I haven't
seen much progress from GCC.

David

--
Sent from Gmail Mobile

reply via email to

[Prev in Thread] Current Thread [Next in Thread]