[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libobjc2 build issue

From: David Chisnall
Subject: Re: libobjc2 build issue
Date: Wed, 27 Nov 2019 11:29:20 +0000
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]