Re: GCC and Clang

[Gregory Casamento]

Riccardo/Po,

On Sun, Feb 13, 2022 at 6:28 PM Riccardo Mottola <riccardo.mottola@libero.it> wrote:

Hi Po Lu,


On 2022-02-11 02:53:07 +0000 Po Lu <luangruo@yahoo.com> wrote:

> Before dropping GCC support in GNUstep, could you please consult with
> the developers of other GNU software which uses GNUstep?
>
> I put quite some effort into getting the GNUstep port of Emacs into a
> presentable state, which I would not have done had it not supported
> GCC.
>
> There are also many machines that aren't supported by LLVM, which a
> Clang-only GNUstep would not be able to run on.

Thank you for your supporting  words.

I, too, appreciate the input.  I am aware that LLVM/Clang doesn't work on many platforms.  If you read the roadmap, you will see that the issues with both paths have their difficulties.

 

> It would be best for someone to work on it, but if nobody does, I
> think
> GNUstep still needs to support GCC, at least for the important
> libraries
> such as gnustep-gui and gnustep-base.

and gnustep-back too :) of course

You seem to be under the false impression that there is a hard dependency on GCC.  From a very strict point of view, NO, it doesn't.  The base, GUI, and back libraries build just fine with no dependence on GCC whatsoever.

That is a direction I want to discuss with other core members.

There was a quorum (as you were not in attendance) of core members there during the initial discussion.  The reason we are having another meeting is to clarify things.

 

Maybe
it is possible with some clever use of macros and perahps defining a
perimeter in methods, or splitting classes and libraries. But a hard
migration for me is unacceptable.

A hard migration was not discussed and was not the intention.  The idea was to draw up a roadmap that shows both ways forward.

This would of course pose a limit: the use of libobjc2 features inside
this "core", e.g. thorugh an upgrade like the scripts David metnioned.

I don't think it would be right to use objc2 features directly inside the "core" libraries (base, GUI, back, etc).  This would limit the ability to use other compilers.   The correct course would be to enable the use of so-called (16 year old) "modern" (ancient, really) features of objc2.  We can compile such things out, if they are not available in whatever compiler is being used.

As already discussed, numerous times, to sum up here very quick...

TL;DR...

1) enhance libobjc2 to work on other platforms.

2) enhance gcc, libobjc, et al. to support more "modern" (as mentioned above) features such as @ literals and, most notably, ARC.

The long pole, between the two of these choices, is debatable.  Enhancing the GCC compiler is possible, but is a lot of work. 

ALso it would be an additional burden buecause two setups should be
tested (but in a certain sense, this is already done, but it is not
diverging).

I think this "migration" was put into air without thinking too much,
but just by the desire of it.

This "migration" or the "desire for it" is 16 years overdue.

Just my 2c here.

Riccardo

Yours,

--

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