I mostly haven’t chimed in here because others covered my points for me. But I feel like reiterating what I said on stream the other night.
As a copyleft and GNU fan, it causes me deep emotional pin that we’re considering targeting something other than GCC as our primary tool chain. BUT We are a small community and if we wish to grow that community, we need to remove barriers. Focusing on feature complete LLVM/libobjc2 might do a lot of this for us. So I am, for now, in favour. I felt the same about our move to GitHub. Actually, I felt more strongly about the GitHub move. But again, I didn’t have the time to help with an alternative. I do think it’s important for us to establish a rule as a community that we don’t depend on LLVM specifics where it’s not absolutely necessary, so that when GCC catches up we can switch back easily. I am not currently able to do the work, but I hope to some day. And I want that process to be easy. Finally, I am willing to donate to a fund that brings GCC up to snuff. And even do some of the work with a patient pair. If anyone put there is capable and has an amount in mind, please discuss. Cheers! -Steven > 14 feb. 2022 kl. 22:05 skrev Gregory Casamento <greg.casame...@gmail.com>: > > Andreas, > > We don't have to tell developers who develop applications that because > GNUstep currently works with clang. Most of the issues mentioned (i.e. "new" > features) are compiler-specific. It is a common misconception that GNUstep > has anything to do with GCC's feature set or that we are, somehow, in control > of features added to GCC due to the fact that we are the major ObjC free > software project. > > 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. > > 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. > > My point during this discussion is and has been that GCC's objc support is > non-existent, so at some point, we will need to make a decision. What I am > hoping to do is to figure out what work needs to be done to make this happen > on both sides (clang and GCC). > > Yours, GC > > On Mon, Feb 14, 2022 at 12:40 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. > > > > > > -- > 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 >
