Re: Clang/LLVM migration roadmap

[Tito Mari Francis Escaño]

Hi everyone,

I think the GNUstep project will have to be pragmatic based on the project goals, and the goals we also have to re-evaluate:

1) Is GNUstep as a project required to be and should  functionally be tied closely with the GCC toolchain?

2) Is GNUstep required to use GCC toolchain to qualify as an FSF sponsored project? This I think is more political than technical in any angle.

3) Is GNUstep valuing technical and functional compability with OpenStep and Cocoa over whatever toolchain to use to maintain that compatibility?

4) Clang/LLVM was initiated by Apple, if I recall correctly, precisely because GCC support for Objective-C is not at par with C and C++ support, will the GCC maintainers be compelled to improve Objective-C support if we stay or we move out?

If we can unanimously answer these questions, I think we can and will move the project forward.

My two cents is that GNUstep project should use whatever tools and platforms that move it's goals and objectives forward.

Thanks.

On Mon, Feb 7, 2022 at 4:31 AM Daniel Boyd <danieljboyd@icloud.com> wrote:

I think the decision needs to tie back to the core mission of the project. I’m not 100% sure what that is. Is it “Grow the GNUStep user base?” Or is it “Maintain a fully copy-left tool chain?” Or some combination?

Honesty, either way, I think llvm/clang is the right choice right now. The project has neither the resources nor the capacity to influence gcc’s ObjC support. In my view, if you want to influence gcc, the best way would be to have 10 times more GNUStep users asking them for better ObjC support. In other words, leverage llvm/clang to grow the user base and then use that to get more clout with the gcc project. 

If you’re looking to recruit more GNUStep users, I just don’t think you can do that without ARC, @[], @{}, etc. There are plenty of ObjC developers out there right now who are potential future GNUSteppers. And as you recruit people, I think “you have to use ObjC instead of Swift” is a much easier pitch than “you have to do manual memory management and type out objectAtIndex: every time you want to get an object from an array”

Just my two cents. 

Sent from my iPhone

On Feb 6, 2022, at 2:02 PM, Gregory Casamento <greg.casamento@gmail.com> wrote:



Fred,

On Sun, Feb 6, 2022 at 2:09 PM Fred Kiefer <fredkiefer@gmx.de> wrote:

> Am 06.02.2022 um 01:14 schrieb Gregory Casamento <greg.casamento@gmail.com>:
>
> There are a number of factors that are driving this:
> --
> 1) GCC lacks support for many memory management features that are commonly used today
> 2) GCC's objective-c support is lagging behind and doesn't include support for @[], @{}, @autorelease, etc etc etc
> 3) Lack of bug fixes in GCC's implementation of ObjC
> 4) GCC team does not consider ObjC release critical and will and HAS released with broken support for building ObjC targets. 
> All of these things are UNACCEPTABLE

Again I beg to differ. Of course the first two point are true and need to be addressed. But I am not aware of any critical bug in gcc that is currently hindering us. There are many missing features and this is really bad for GNUstep and ObjC as a whole. As for the position of the gcc team on ObjC, none of knows and we only may guess here. The one time where a gcc release knowingly broke ObjC was ages ago. Maybe it could happen again, we just don’t know. Stating something as a fact that is just a possibility is a rather annoying habit of our times. Please don’t do so on the GNUstep mailing list.

I am not sure the last time I saw a significant bug fix in the objc code in GCC.

As is typing words in all capital letters. It really doesn’t help in polite conversations.

Fred

GC

--

Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
https://www.patreon.com/bePatron?u=352392 - Become a Patron

https://gf.me/u/x8m3sx - My GNUstep GoFundMe

https://teespring.com/stores/gnustep - Store