| 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
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
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.
--
|