> On Feb 15, 2022, at 2:07 AM, Gregory Casamento <greg.casame...@gmail.com> > wrote: > > > Max, > > When coming to merging, I am okay if those two branches never truly merge. > > I'm not.
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.) > >> On Feb 14, 2022, at 4:08 PM, Gregory Casamento <greg.casame...@gmail.com >> <mailto:greg.casame...@gmail.com>> wrote: >> >> 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 Mon, Feb 14, 2022 at 3:11 PM Max Chan <xcvi...@me.com >> <mailto:xcvi...@me.com>> wrote: >> >> >> > On Feb 14, 2022, at 12:39 PM, Andreas Fink <af...@list.fink.org >> > <mailto:af...@list.fink.org>> wrote: >> > >> > >> > >> > Richard Frith-Macdonald wrote on 14.02.22 17:43: >> >> >> >>> On 14 Feb 2022, at 14:59, Max Chan <xcvi...@me.com >> >>> <mailto:xcvi...@me.com>> wrote: >> >>> >> >>> >> >>>> On Feb 14, 2022, at 8:23 AM, Richard Frith-Macdonald >> >>>> <rich...@frithmacdonald.me.uk <mailto:rich...@frithmacdonald.me.uk>> >> >>>> wrote: >> >>>> >> >>>> >> >>>> >> >>>>> On 14 Feb 2022, at 11:43, Max Chan <xcvi...@me.com >> >>>>> <mailto:xcvi...@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. >> >> >> -- >> Gregory Casamento >> GNUstep Lead Developer / OLC, Principal Consultant >> http://www.gnustep.org <http://www.gnustep.org/> - >> http://heronsperch.blogspot.com <http://heronsperch.blogspot.com/> >> https://www.patreon.com/bePatron?u=352392 >> <https://www.patreon.com/bePatron?u=352392> - Become a Patron >> https://gf.me/u/x8m3sx <https://gf.me/u/x8m3sx> - My GNUstep GoFundMe >> https://teespring.com/stores/gnustep <https://teespring.com/stores/gnustep> >> - Store > > > > -- > Gregory Casamento > GNUstep Lead Developer / OLC, Principal Consultant > http://www.gnustep.org <http://www.gnustep.org/> - > http://heronsperch.blogspot.com <http://heronsperch.blogspot.com/> > https://www.patreon.com/bePatron?u=352392 > <https://www.patreon.com/bePatron?u=352392> - Become a Patron > https://gf.me/u/x8m3sx <https://gf.me/u/x8m3sx> - My GNUstep GoFundMe > https://teespring.com/stores/gnustep <https://teespring.com/stores/gnustep> - > Store
signature.asc
Description: Message signed with OpenPGP
