[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libobjc2 build issue
From: |
Fred Kiefer |
Subject: |
Re: libobjc2 build issue |
Date: |
Thu, 28 Nov 2019 09:12:12 +0100 |
> Am 27.11.2019 um 12:29 schrieb David Chisnall <gnustep@theravensnest.org>:
>
> 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.
> ….
> 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, I can understand that after all these long mail threads you over react
on my statements. But part of what you write is so much out of place and
character that I was really surprised. Let us first get the facts straight,
facts that I am sure you are aware of:
- GNUstep base is CI tested for clang in two different setups and nobody ever
wanted to change this.
- I had been using a Docker image with Ubuntu, clang, libdispatch and
everything to bug test GNUstep base with Coverity.
- I have always advocated the usage of as many different setups for GNUstep as
possible.
I wrote about my private development setup, that this is gcc based and the
reason for it. The reason was not that I reject the great development that has
happened in clang and libobjc2, which I really admire. It was a decision of
personal preferences and one of optimising my time spend on GNUstep. I know
that GNUstep gets used and tested with clang by others, I choose to provide the
gcc support for it. I never tried to enforce this decision on anybody else.
As for my local Docker image for Coverity, Docker stop to work on my MacBook
Pro half a year ago. That is why we never got Coverity scans for gui and
haven’t had any for base in half a year. What was the reaction from the GNUstep
developers? Nothing. Coverity scans, although something we discussed in Dublin
as well, were my private hobby. Apart from Richard looking into all the
reported issues at the time I never go much feedback on that. I can live with
that. This is a free software project. Everybody has the right to only follow
his/her personal preference. David, you used to share this position. It looks
like this has changed.
Fred
- Re: libobjc2 build issue, (continued)
- Re: libobjc2 build issue, Johannes Brakensiek, 2019/11/26
- Re: libobjc2 build issue, Fred Kiefer, 2019/11/26
- Re: libobjc2 build issue, Andreas Fink, 2019/11/26
- Re: libobjc2 build issue, Patryk Laurent, 2019/11/26
- Re: libobjc2 build issue, Andreas Fink, 2019/11/26
- Re: libobjc2 build issue, Patryk Laurent, 2019/11/27
- Re: libobjc2 build issue, Fred Kiefer, 2019/11/27
- Re: libobjc2 build issue, Johannes Brakensiek, 2019/11/27
- Re: libobjc2 build issue, David Chisnall, 2019/11/27
- Re: libobjc2 build issue, Johannes Brakensiek, 2019/11/27
- Re: libobjc2 build issue,
Fred Kiefer <=
- Re: libobjc2 build issue, Andreas Fink, 2019/11/27
- Re: libobjc2 build issue, David Chisnall, 2019/11/27
- Re: libobjc2 build issue, Andreas Fink, 2019/11/27
- Re: libobjc2 build issue, David Chisnall, 2019/11/27
- Re: Which ObjC2.0 features are missing in the latest GCC?, Ivan Vučica, 2019/11/26
- Re: Which ObjC2.0 features are missing in the latest GCC?, Maxthon Chan, 2019/11/26
- Re: Which ObjC2.0 features are missing in the latest GCC?, Ivan Vučica, 2019/11/26
- Re: Which ObjC2.0 features are missing in the latest GCC?, Maxthon Chan, 2019/11/26
- SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), Ivan Vučica, 2019/11/27
- 回复: SwiftUI compatibility APIs in GNUstep's graphics stack (Was: Which ObjC2.0 features are missing in the latest GCC?), Max Chan, 2019/11/27