[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should we split the project into two branches?
From: |
Max Chan |
Subject: |
Re: Should we split the project into two branches? |
Date: |
Mon, 14 Feb 2022 15:10:53 -0500 |
> On Feb 14, 2022, at 12:39 PM, Andreas Fink <afink@list.fink.org> wrote:
>
>
>
> Richard Frith-Macdonald wrote on 14.02.22 17:43:
>>
>>> On 14 Feb 2022, at 14:59, Max Chan <xcvista@me.com> wrote:
>>>
>>>
>>>> On Feb 14, 2022, at 8:23 AM, Richard Frith-Macdonald
>>>> <richard@frithmacdonald.me.uk> wrote:
>>>>
>>>>
>>>>
>>>>> On 14 Feb 2022, at 11:43, Max Chan <xcvista@me.com> wrote:
>>>>>
>>>>> Dear List,
>>>>>
>>>>> There are over and over again arguments on moving on to LLVM/clang for
>>>>> latest language features versus maintaining compatibility with
>>>>> old/uncommon platforms and GCC,
>>>> Really this is simply not the case among GNUstep developers.
>>>> Those of us who actually use the stuff just work with whatever we
>>>> prefer/need, because GNUstep already works with both toolchains.
>>> The hard requirement of allowing building using GCC means we are restricted
>>> to language features equivalent of OS X 10.6.8 or iOS 4.3.5,
>> Please don't spread such nonsense on the mailing lists.
>>
>> The fact that we have a huge base of code that builds with both GCC and
>> clang (and a small part that only functions when built with clang) in no way
>> restricts us in the way we write new code.
>>
>> Having highly portable code is a strong point, but that doesn't mean that
>> *all* features are equally portable or that contributors are required to
>> write perfect portable code.
>>
>> It does the project a huge disservice to tell developers they 'have to use
>> an ancient version of the language'. Please don't do it.
>
> It does the project a huge reality check to tell developers they 'have to use
> an ancient version of the language *IF THEY WANT TO CONTRIBUTE TO GNUSTEP*'.
> That's says it all.
That is kind of my point. The mainline branch focuses on maintaining the highly
portable codebase, while the Next branch focuses on features and library
support, free to break compatibility with anything that is less than popular in
the wild. The popular targets IMO are Linux-amd64, Windows-amd64 and
Linux-aarch64, maybe Linux-armv7.
I wished we could support Swift language and Swift-ObjC interoperability, but
that will likely require a major refactor to libobjc2, base and corebase, and
maybe even a new ABI. Those are the core parts of GNUStep where compatibility
is of the utmost importance, but Swift compatibility is likely going to end up
requiring breaking changes. Swift interoperability brings in Swift Package
Manager, which can be a modern replacement for gnustep-make. That change to the
build system likely will also break compatibility.
Also, if we are willing to accept breaking changes even just on a branch, we
may even start incorporating Appleās Apache-2.0 code in this project, taking
bits and pieces from that open source release of Swift language. For example
AFAIK there is an Objective-C runtime core in libswift that is both ObjC 2.0
compliant and very performant, which may even be a fork of the version of
libobjc Apple used in macOS and iOS, maybe we can just nab that to make our
libobjc2 more performant.
signature.asc
Description: Message signed with OpenPGP
- Re: Should we split the project into two branches?, (continued)
- Re: Should we split the project into two branches?, Andreas Fink, 2022/02/14
- Re: Should we split the project into two branches?, Frederik Seiffert, 2022/02/14
- Re: Should we split the project into two branches?, Frederik Seiffert, 2022/02/14
- Re: Should we split the project into two branches?, Riccardo Mottola, 2022/02/14
- Re: Should we split the project into two branches?, Max Chan, 2022/02/14
- Re: Should we split the project into two branches?, Riccardo Mottola, 2022/02/15
- Re: Should we split the project into two branches?, Max Chan, 2022/02/15
- Re: Should we split the project into two branches?, Andreas Fink, 2022/02/15
- Re: Should we split the project into two branches?, Max Chan, 2022/02/15
- Re: Should we split the project into two branches?, Andreas Fink, 2022/02/15
- Re: Should we split the project into two branches?,
Max Chan <=
- Re: Should we split the project into two branches?, Gregory Casamento, 2022/02/14
- Re: Should we split the project into two branches?, Max Chan, 2022/02/14
- Re: Should we split the project into two branches?, Gregory Casamento, 2022/02/15
- Re: Should we split the project into two branches?, Max Chan, 2022/02/15
- Re: Should we split the project into two branches?, H. Nikolaus Schaller, 2022/02/15
- Re: Should we split the project into two branches?, Max Chan, 2022/02/15
- Re: Should we split the project into two branches?, Richard Frith-Macdonald, 2022/02/15
- Re: Should we split the project into two branches?, Hugo Melder, 2022/02/14
- Re: Should we split the project into two branches?, Derek Fawcus, 2022/02/15
- Re: Should we split the project into two branches?, H. Nikolaus Schaller, 2022/02/15