Re: Improving GNUstep tooling with Clang

[Fred Kiefer]

Thank you Frederik for this patch. I already reviewed and merged it, as I want 
to get this going.

One small correction, gcc should be able to work with release 1.9 of the 
GNUstep libobjc. We just never tested this setup.

Getting out packages with the new setup will be a lot more work. Hopefully 
there are some volunteers to support this.

Cheers,
Fred

> Am 28.11.2019 um 17:15 schrieb Frederik Seiffert <frederik@algoriddim.com>:
> 
> 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.
> 
> Given the above I would like to propose improving and unifying the experience 
> for Clang users with changes like the following:
> 
> - Define which library combo and runtime version is the recommended one for 
> Clang users, and change the defaults in make/base to reflect that.
> As far as I can see the current defaults are "gnu-gnu-gnu" with the gcc 
> runtime; when the user selects the ng library combo the 1.8 runtime version 
> is used. Changing the default runtime version is non-obvious or well 
> documented and requires building make with a user config file containing e.g. 
> "RUNTIME_VERSION=gnustep-2.0".
> I would propose to change the default to "ng-gnu-gnu" and the 2.0 runtime 
> version when a sufficiently recent Clang version (to be defined by David) and 
> libobjc2 are detected.
> 
> - Set up CI testing for the 2.0 runtime version, which currently doesn’t seem 
> to be tested with libs-base.
> I have submitted a pull request for this 
> (https://github.com/gnustep/libs-base/pull/88).
> 
> - If possible provide updated packages with the new recommended setup for the 
> various distributions (if needed as a new major revision).
> 
> The above could unify Clang users with a common, better tested, and easier 
> setup, and thus make it more straightforward to use modern Objective-C 
> language features in own code with GNUstep. And maybe it will also allow more 
> people to use and get acquainted with modern ObjC features like ARC, blocks, 
> and generics. Coming from Mac/iOS development, I think you’ll have a hard 
> time finding a developer there who doesn’t use and take these features for 
> granted.
> 
> Note that none of this would break support for existing GCC setups. It would 
> also not force anyone to e.g. adopt ARC, but it would allow anyone to easily 
> enable it in their own projects by adding -fobjc-arc to their compiler flags 
> (ARC and non-ARC can be easily mixed, so this also works if libs-base doesn’t 
> use ARC).
> 
> As I said I’m fairly new to GNUstep so I’m likely missing some things, but 
> maybe this could be part of a path forward from the recent discussions.
> 
> Thanks,
> Frederik
> 
>