Re: Which ObjC2.0 features are missing in the latest GCC?

[Riccardo Mottola]

Hi,


On 11/23/19 11:29 PM, Ivan Vučica wrote:
> On Fri, Nov 22, 2019 at 8:02 PM Yavor Doganov <yavor@gnu.org> wrote:
> > The answer is simple: because there's a
> > lot to lose and nothing to gain.
> As someone that does want to see GCC have continued support in
> GNUstep's core libs, and as someone who has been happy in an ARC-free
> world, and as someone that's very appreciative of work being put into
> keeping GNUstep available in Debian:


I am also very happy :-P All parts of the GNUstep "desktop" environment 
I assemble and which I work on since the first day of my involvement in 
GS, build without C++ or Objc 2.0 stuff, except one: PDFKit. About 
PDFKit I need to decide its future (currently I am unable to upgrade it 
to 4.x), together with GSPdf.


> This is unfortunately wrong. There is a lot to gain. Developers who
> want to start using Debian-built GNUstep libraries can start using
> tons and tons of features that GCC and GCC runtime do not support.
> Most have been outlined throughout this thread, but here's some that
> come to mind:
>
> - ARC is one.
> - Blocks is another.
> - @123 syntax for NSNumber (and similar stuff for arrays and dicts and
> more) is another.
> - Improved @property support is yet another.


These features are useful for programmers who wish to use them. So, 
actually, for the end-user if would be equivalent if e.g. Rik's theme 
could be made working with GCC (I don't know if it is possible, speaking 
hypothetically) or not.

It does us a greater disadvantage for people who instead like to install 
GNUstep on Debian to use it as a development environment and thus want 
to code or port software which uses these new features.


> I'm not dependent on any of these. But I'd say that Debian's packaging
> of GNUstep is very important and even if the core doesn't start
> depending on these features, they should be made available.
>
> What's lost is builds on some architectures. Can't those architectures
> keep using GCC-targeting libraries or be actively disabled? Even if
> the core and GCC support these architectures, do Debian packages have
> to ship for them?


As far as I know, this is not possible on Debian: compilers get risen 
together.

Also, for example, on OpenCSW, where GS is build with GCC, keeping 
different compiler version for different Solaris versions is possible, 
but quite a nuisance: so the approach "one compiler suits all packages" 
is often a simplifying choice for build infrastructures.


Riccardo