Re: libobjc2 build issue

[David Chisnall]

On 27/11/2019 08:37, Fred Kiefer wrote:
> For me this reoccurring build issues are one of the reasons why I do not use 
> clang and the new runtime. They both develop too fast for me. It is quite 
> normal that things change and from time to time they are even broken. If I 
> remember correctly most of the questions on the development mailing list in 
> recent years where caused by this. I prefer to spend my little time on GNUstep 
> itself and not on fixing the build infrastructure. (Resulting in a less than 
> optimal GNUstep environment for me.) What we need to do is minimise the pain 
> for people who choose the other way.

Fred, with respect, this is one of the main reasons the developer 
experience for GNUstep is so bad: the core developers are not eating 
their own dogfood.  If our message to people is 'sure, GNUstep works 
with the latest Clang and all of the features that someone who learned 
Objective-C in the last decade expects, but we can also compile it with 
GCC' and that really means 'we only test it with GCC, but we hope it all 
works with the new stuff' then we're really saying 'don't bother trying 
to use the new stuff, no one tests it so it's probably broken'.

I have CI for the runtime on:

 - Ubuntu
 - Windows
 - FreeBSD
 - macOS (though only the old ABI)

I fix bugs as they are filed and the CI scripts show how to build on any 
of these platforms.  It depends on a recent clang release, but this is 
available as a binary package on all of those platforms and then the 
build process is exactly the same as any other CMake.  A quick grep of 
the FreeBSD ports tree tells me that this is over 1615 packages and a 
look at the list shows that it's a lot of the very popular ones (e.g. 
KDE, LLVM), so this isn't some esoteric build system.  CMake is even 
supported out of the box by Visual Studio now.

Many of the issues that I've fixed over the last year or two were only 
apparent when people started using non-trivial things using ARC.

We shipped an ARC implementation in 2011.  Since then, how many of the 
active GNUstep developers have worked in a configuration where they were 
stress testing support for this configuration?

There were a total of 14 commits to the runtime's ARC code between 2012 
and 2017 inclusive, an average of under 3 a year.

There have been 23 commits to that code in 2018 and 2019 *because people 
have been using it and reporting bugs*.  The main bugs that were fixed, 
which were difficult or impossible to trigger in unit tests:

- Andreas found perf impacted on a 24-core machine by the fact that 
every object that was being deallocated acquired a mutex to serialise 
deallocation with respect to weak loads.  We now only do that for 
objects that have ever had a weak pointer taken to them.  We could 
improve it by sharding the locking if necessary.

- Frederik hit an issue with hash collisions that was triggered only 
when you had a lot of weak pointers in a program.

- Jordan reported an issue where weak pointers were seeing memory 
corruption as a result of reading uninitialised data.

Note the names of these people: none of them are core GNUstep 
contributors.  All of these issues would have been found earlier if 
GNUstep developers had started using ARC in 2012, when it was more or 
less stable.

The same is true for the NS{Hash,Map}Table bugs that I fixed over the 
weekend.  If core GNUstep developers were using weak object map tables 
(if, for example, NSNotificationCenter used one for the registered 
observers) then these issues would have been apparent years ago and 
would have been fixed.

I am no longer actively working on Foundation or AppKit, so I shouldn't 
get much of a say in what those projects do, but if GNUstep is going to 
be tested with only GCC then my advice would be:

 - Actively market GNUstep as only an OpenStep implementation, drop all 
Cocoa references.

 - Drop support for Clang.

Currently, the project is setting itself up to fail by advertising 
features that no one tests.

David