discuss-gnustep
[Top][All Lists]
Advanced

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

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


From: Max Chan
Subject: Re: Which ObjC2.0 features are missing in the latest GCC?
Date: Sun, 24 Nov 2019 17:11:10 +0800

I would like to add another plus for dropping GCC: if we want any hope for Swift interworking, we have to use clang as the compiler.

Apple have no plan to provide any GUI support on Linux version of Swift. If we have Swift interworking, even though we may have to drop our own libobjc, Foundation and CoreFoundation in favor of Apple’s release, the GNUStep GUI package can provide the replacement AppKit that Apple’s Swift release lacked.

顺颂商祺
陈北宗 Max Chan, from SushiBits Projects
Tel. +86 186-2165-8748
https://github.com/SushiBits

On Nov 24, 2019, at 15:21, Johannes Brakensiek <address@hidden> wrote:



On 24 Nov 2019, at 2:24, Yavor Doganov wrote:

Ivan Vučica wrote:

On Fri, Nov 22, 2019 at 8:02 PM Yavor Doganov <address@hidden> wrote:

The answer is simple: because there's a lot to lose and nothing to
gain.

This is unfortunately wrong. There is a lot to gain.

Right or wrong depends on the point of view, which ultimtately boils
down to one's values and beliefs. What is gain for some may be loss
for others. It appears we have different values, hence the
discrepancy.

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.

Developers who want to start using these new (not so new -- 10 years
old!) features have the option to build the environment they need on
top of Debian (if that is their distro of choice) or switch to another
distro that provides prebuilt packages.

But that is the wrong answer.

You, developers, tend to forget that free software is for users.
Developers are users too in a broad sense but they are a very small
part of the whole mass of people using a particular piece of software.
If these fancy features existed for 10 years, why they have not
inclined developers to write more free software that is relying on
them? Surely that's not because Debian stopped them? Or because the
GNUstep project is stopping them?

My task as a free software contributor (with the extremely limited
skills I have) is to help achieve the goals of the Free Software
Movement. Providing "tons and tons of features" to developers who
don't care at all about free software (at least the majority of them)
and who won't write a single line of code for the cause I'm aligned to
doesn't strike me as the "right" thing to do.

I don't mind helping them as a side effect of helping free software.
In this case, however, it is all about them.

- 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.

This is like offering rocket fuel to someone who has a car with a
diesel engine. None of the packages in Debian is using these
features, which is why I said there's nothing to win. There's a queue
of software packages we intend to package in Debian but neither of
them depends on these things -- except probably the Rik theme and
NEXTSPACE (which are not suitable for packaging for other reasons).

Right now I'm working on a new upstream release of a package which
uses NSNotificationCener-addObserverForName:object:queue:usingBlock:.
This is a method which is declared and supposed to be supported even
with GCC, I just don't know the (GCC) syntax I'm supposed to use so
I'm experimenting with GCC nested functions as replacement. If that
fails, I guess I'll solve it somehow, using a different approach.
That's the first case I face ever -- I've seen methods using blocks in
upstream code before but they were no-op anyway as there was no
GNUstep implementation. On the contrary, there are tons of
block-unrelated things which are not implemented, especially in GUI.

The biggest hurdle with porting apps IMVHO is missing functionality
and dependency on Core* stuff and other libraries with no free
implementation. The switch to Clang is not going to solve these
problems. The only thing it solves is making the life of developers
of properiatary software easy. That is not my goal.

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.

I don't know why Debian is important, but they cannot be made
available as an option. It would mean duplicate packages with
different names -- the release team will not allow it and the
ftpmasters will not allow it.

You probably weren't around when we (GNUstep people in Debian) had to
scrap and fight to prevent it from being removed. GNUstep in Debian
back then was undermaintained and violated the FHS, it was also full
of bugs (that is, obvious bugs such as frequent failures to build from
source) and blatant bugs solely due to packaging. Hubert wrote a tool
to FHS-ify most of the packages, we fixed most bugs and we had a
helping hand from the Debian GCC maintainers who said it would be very
worthwile to keep GNUstep in Debian, at least as a testing ground for
GCC.

And that's what it's been, more or less; GNUstep had a rapid decline
in the user base some years ago and it appears it is not going to
recover. All the Clangs in the world are not going to help you with
that. But in your quest for popularity you may lose some of the solid
foundations that are still keeping this project afloat.

What's lost is builds on some architectures. Can't those architectures
keep using GCC-targeting libraries or be actively disabled?

No. Packages which no longer build for a particular architecture must
be removed manually by the ftpmasters, after a request is filed. If
the architecture is official (meaning it is officially supported in
the stable version of the distro about to be released) it must be
decided by the release team.

In case it still isn't clear -- I repeat, there is no middle ground to
support both compilers/runtimes.

Hey Yavor,

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 seems to me you are making this a „the egg or the chicken“ problem, which it isn’t. 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. (You know the good old enemy yelling „developers, developers, developers“. He was right.)

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.

Just one last thing to add: Cocoa/Mac software development is not the same as proprietary software development. There is a lot of good quality free software for Cocoa which would be of great use if it could be ported to a free desktop environment. To just mention a few:

I think many here know a lot more.

Just my two cents. Thank you for your work and endorsement for free software and Debian packaging!
Johannes


reply via email to

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