Re: Should we split the project into two branches?

[Max Chan]

> On Feb 14, 2022, at 6:18 PM, Riccardo Mottola <riccardo.mottola@libero.it> 
> wrote:
> 
> 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.

To be honest ARC is less of a concern for me right now - GCC can gain that (and 
the syntactic sugars) very easily as long as GCC folks can pick up their s#!t. 
The big feature of concern IMO is Swift, which does not have any GCC frontend 
and likely uses a different ABI as what we are using.

Our core library IMO is 10.6.8 + backports + an entirely twisted library 
layering in dire need of refactor, especially if we want to bring in Swift 
support. The biggest refactor project we need to undertake IMO is actually 
layering our CoreFoundation beneath Foundation instead of on top of it, as that 
is also a dependency of Swift Standard Library.

signature.asc
Description: Message signed with OpenPGP