discuss-gnustep
[Top][All Lists]
Advanced

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

Re: libobjc2 build issue


From: Riccardo Mottola
Subject: Re: libobjc2 build issue
Date: Sun, 1 Dec 2019 11:17:02 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2

Hi,


On 11/28/19 9:12 AM, Fred Kiefer wrote:
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.


Right. Please do not distort things. While I make sure that everything is "gcc clean" for my own use, I do test, run and build GNUstep with clang almost daily. My main workstation is FreeBSD + Clang + GNUstep. Of course, it means I do not use any features of this setup that would not work in the equivalent GCC path, but it still gets used. All software I run or maintain works in this setup.

Actually, the reason why Clang is set up only there is because it is the only path: every attempt to use GCC on FreeBSD failed, but also, FreeBSD gives me directly working objc-2 runtime, something which elsewhere is a pain or not setup as I like (again: proves the importance of ready packages)

On other setups, trying to get a working Obj-C runtime might be a nightmare or close to impossible. For whatever reason, be it horrible cmake or some other obscure header, C++... everytime it is different.


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.


Not true "nothing".. but I got swamped with "dayjob" issues and one of that had an impact on GNUstep too - Windows support, something i could not yet solve to satisfaction

I hope in 2020 we can meet again and do our nice "hacking" again, since it has always been fun and productive too.


Riccardo




reply via email to

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