When coming to merging, I am okay if those two branches never truly merge.
Come to think of it, if we do chase the latest feature especially Swift compatibility, we get Swift Package Manager along with it which can be used as a parallel build system bypassing gnustep-make. This means that with the exception of a few libraries that Swift itself would depends on requiring extensive use of conditionals, every other package can have two basically independent sets of build scripts, one based on gnustep-make, and the other being Package.swift for SPM. Files included in the Makefiles would require compatibility with the outdated languag in GCC and work with the legacy targets, while Package.swift-only files can use the latest features, including the use of Swift language, since the build environment would require Swift to begin with. NeXT branch? Since when are we still tracking with NeXTSTEP/OPENSTEP? Also, as I said to your first iteration of this idea, it creates too much division.
It is not NeXT, it is the next version of GNUstep. It is important to note that, while LLVM/Clang is used in Swift that Swift is not dependent on it. That is to say ... swift interoperability can be done without LLVM.
Can you point me to a production ready version of Swift compiler and standard library that is not based on LLVM? Is there a gswiftc? (Actually if there is a gswiftc they would have to fix up ObjC first.)
Having so many branches will confuse things greatly. I am not sure it's a good idea to split the project like this. Also, with many branches divergence becomes a greater possibility which might complicate merging.
> 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