[Top][All Lists]

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

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

From: Yavor Doganov
Subject: Re: Which ObjC2.0 features are missing in the latest GCC?
Date: Sun, 24 Nov 2019 15:16:15 +0200
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (Gojō) APEL/10.8 EasyPG/1.0.0 Emacs/26 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

Johannes Brakensiek wrote:
> would it be possible to somehow ship a clang runtime on Debian or
> isn’t it? If it is how could it be achieved?

It is possible but not as an option/alternative.  Either the whole
GNUstep stack moves to Clang + the new runtime or it stays with GCC +
the GCC runtime.

To achieve the former, a preliminary discussion with the release team
must be held, to sound their opinion about dropping architectures for
about 85 packages, the transition plan and the way to solve the
inevitable file conflict between libobjc4 (the GCC runtime) and
for example libobjc2-4 (the new runtime).  That's where the GCC
maintainers' opinion should be taken into account.

I guess the release team won't have any objection to dropping
unofficial architectures but if s390x/ppc64el/mips* have to be dropped
as well there could be a problem.

Then a transition should be carried out, fixing all the bugs and
dealing with all the issues that will arise, both for the core
libraries and the reverse dependencies.

Oh, and a decent rationale for the switch must be provided.  If none
of the present packages will benefit from the switch, it is hard to
justify it.

> It seems to me you are making this a „the egg or the chicken“
> problem, which it isn’t.

Yes it is.  Libraries and development tools are building blocks that
help developers to write programs.  If a program is useful and worth
packaging, a Debian maintainer starts by packaging the tools and
libraries it needs and then by packaging the program itself.

Packaging libraries and development tools just because they are cool
and it is expected that hordes of developers will write useful
programs that utilize them is not a useful activity -- you have to
justify their inclusion in the distro and a hypothetical future
benefit is not a good argument.

> If you don’t provide new tools for developers they are not going to
> build new software for their users. It’s this way around not the
> other and it’s no dilemma at all.

So you are basically saying that just because Debian does not provide
the right tools there is no software written yet?  Sorry to say that
but it's a ridiculous statement.

> For me this cause is indeed a decision whether you are most
> comfortable with the state in which GNUstep currently is or if you
> would be more comfortable when it would develop to a further state,
> maybe one where most ObjC currently is. If you want it to develop the
> decision should be simple.

This is a bogus argument, GNUstep supports these new features and
developers who want to use them can do so.  Debian cannot stop them.

> Just one last thing to add: Cocoa/Mac software development is not
> the same as proprietary software development.

No, but free Cocoa software is in the same position as the "Java Trap"
back when Java was proprietary.  Here GNUstep comes to the rescue, but
very few of their developers value freedom.  They just want to get
their app on some store and that's it.

> - https://github.com/64characters/Telephone
> - https://github.com/subethaedit/SubEthaEdit
> - http://colloquy.info/
> - https://github.com/rburgst/time-tracker-mac

Are these projects directly buildable/runnable with GNUstep configured
for Clang and the modern runtime?  I doubt it.

reply via email to

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