discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Should we split the project into two branches?


From: Riccardo Mottola
Subject: Re: Should we split the project into two branches?
Date: Tue, 15 Feb 2022 00:18:19 +0100
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 SeaMonkey/2.53.10.2

Hi,

Gregory Casamento wrote:
> GNUstep's core code tries to remain as compatible as possible with both
> tool-chains.  This is done very much on purpose.  When using clang, you
> can use many of the ObjC2.0 features.  The main one missing is ARC, and
> that is the main one I am concerned about.

But why is ARC usage a concern in the core libraries? it is not strictly
needed.
Since ARC could be implemented in GCC in some future, the isue is not
clang vs, gcc, but ARC or not mandatory in core; our point is having:
1) have gnustep core be compatible with ARC, we should be that already
2) have gnustep core explot and depend on ARC, that would rule out "old
compilers"

since even if a future version of GCC may support ARC, for many years
operating system distributions, especially ESR versions, will not
distribute it. So we should try to support non-ARC "forever".
This could mean that some methods and/or classes could become available
for ARC only
But I would not do it "10.6.8 API wise". We already support much newer
stuff without using ARC, we oculd even decide a certain method or class
is so important to be inlcuded by rewriting in the non-ARC core.

The only nuiseance of this is that by having "shells" of back on gui on
base... if we add a feature in an ARC.only way, it cannot be used by a
"non-ARC" code in any of the upper layers. However this can be of course
easily checked by compiling and testing, exactly as Frederik is doing
right now with his contributions.

> Apple isn't concerned with remaining compatible with any other compiler,
> so they were free to move completely to LLVM/Clang and use its features
> in their implementation of the frameworks.   According to discussions,
> this saved Apple a lot of code and time debugging memory issues.  We
> don't have that option since our priority is freedom.

Apple has also the freedom to ship a new XCode version and give you the
old SDK and old compiler for a while and then drop it. We want to do
more and cater with one setup. We can do better and at the end we have a
better track record of support than Apple!

Riccardo



reply via email to

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