Improving GNUstep tooling with Clang

[Frederik Seiffert]

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