| I wonder if this is the correct understanding, using how things happened with Apple as a parallel:
* The old libobjc would be similar to Apple’s ARC-lite shipped in Mac OS X 10.6.8 or iOS 4.3. It will support some new features (eg syntactic sugars) but will have limitations on maintenance etc. * The new libobjc2 is required for all new language features Apple have added (eg Blocks) since then, with a big one IMO being any hope of integrating with the open source release of Swift language.
One thing we may need to do, is somehow make both libobjc use the same ABI.
p.s. GNUstep’s separation of gnustep-gui (AppKit) and gnustep-back can make reimplementing UIKit and SwiftUI that much easier. The latter will likely be a written in Swift but make heavy use of Swift-ObjC inter-compatibility to call into gnustep-back. Sent from my iPad On Feb 13, 2022, at 9:03 PM, Gregory Casamento <greg.casamento@gmail.com> 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
--
|