Re: Improving GNUstep tooling with Clang

[Richard Frith-Macdonald]

> On 28 Nov 2019, at 16:15, Frederik Seiffert <frederik@algoriddim.com> wrote:
> 
> Hi all,
> 
> In the wake of the recent discussions about GCC, Clang, and modern 
> Objective-C features, I wanted to share some observations and propose some 
> improvements.
> 
> As a recent newcomer to the GNUstep community, one of the things that made 
> building GNUstep difficult was understanding the various configuration 
> options and their implications and interdependencies, most notably the 
> different "library combos" and libobjc2 runtime versions, which e.g. depend 
> on the Clang version being used and affect which modern Objective-C language 
> features are supported.
> 
> With 2 language combos (gnu and ng) and 3 runtime versions (gcc, 1.9, 2.0), 
> this leaves Clang users with at least 5 different build variants, some of 
> which significantly differ in their abilities. In contrast, if I understand 
> it correctly GCC only supports one library combo and runtime. I could imagine 
> that this might also play a role in many people sticking to GCC with its 
> simplicity, and obviously it creates quite a large test surface that makes it 
> more likely for bugs to go unnoticed.

I think there's some confusion here.

gnu-gnu-gnu is the combo for classic objc (gcc and the old runtime)
ng-gnu-gnu is the combo for objc2 (clang and the new runtime)

We decided to adopt that simplified scheme a few years ago.  So while 
deveoplers are of course free to mess around with any combination of 
compilers/libraries/flags they like, there are really only those two variants 
supported for normal use.

With ng-gnu-gnu, gnustep-make lets you enable/disable ARC and you can 
experiment with the very latest runtime version using RUNTIME_VERSION. 

Yes the plan is to update the default runtime version for ng-gnu-gnu to be 2.0 
in the next release (though it would be good to have the 2.0 runtime build more 
easily/realiably first).
The reason ARC is not enabled by default is that it would break most existing 
software packages when building with ng-gnu-gnu, but maybe that could change in 
future.