On Tue, Nov 26, 2019 at 12:17 PM Gregory Casamento <address@hidden
I personally don't like off list discussions it makes things a little more complicated than they need to be.... that being said...
Yes... Only after I hit the send button did I realize I had not selected "Reply All". I'm adding mailing list back in so that folks can see your reply.
On Tue, Nov 26, 2019 at 10:43 AM Stefan Bidigaray <address@hidden
On Tue, Nov 26, 2019 at 4:55 AM Gregory Casamento <address@hidden
I'd really like some resolution on this topic. There seem to be a lot of reasons for and against.
I've managed to stay quiet throughout this discussion because I wanted to hear some of the arguments and counter-arguments before formulating my own opinion. As of this moment, I'm still not convinced that dropping GCC is a good choice.
I believe dealing with an all-or-nothing option is not the right attitude. At the end of the day, completely dropping GCC is going to cause major disruption to the project. The fact is that some developers will be left out in the cold if/when this happens. Another argument is, for all it's flaws, GCC is the standard compiler on most Linux distributions (any of the ones using glibc, since it does not build with clang), so it is something that we get "for free".
How about a compromise? How hard would it be for GCC to drop the GCC runtime in favor of GNUstep runtime, and implement everything except ARC and blocks (these seem to be the biggest road blocks)? While ARC and blocks are important for many developers, GNUstep itself is not directly dependent on the compiler supporting these features. Ideally, we could get to a situation where GCC and Clang compiled binaries can interoperate. Or am I way off?
GNUstep is absolutely and TOTALLY dependent on the compiler for these things. ARC is done by the compiler at build time. Blocks are also a feature of the compiler. GCC has neither of these features.
Let me clarify what I said... Currently, GNUstep does not require the compiler to support ARC nor blocks. Memory-management is currently done manually, and macros like
CALL_BLOCK() allows us to call blocks without specifically requiring compiler support. While these 2 features are really nice, they would also require a lot of work to implement, as David pointed out.
One more questions... what do the GCC Objective-C maintainers have to say about this discussion? It would seem that GNUstep is now their only downstream "customer". Are they open to working with us to provide a more compatible compiler?
They haven't seen this discussion. They would likely expect us to make these changes ourselves and, as David Chisnall pointed out... there is about 2 man years of work there.
I completely understand that part. My suggestion was to How long would it take to implement all the language features, except ARC and blocks, in GCC? Could we implement the non-fragile ABI, @properties, generics, etc. in a reasonable amount of time?
How hard to replace the GCC-runtime with the GNUstep-runtime?
If this is more palatable, then is it a worthwhile avenue to pursue?
My suggestion is, essentially, to get GCC to a more compatible position.
At the end of the day, GNUstep has been around for a very long time, and like it or not, backward-compatibility is important. I personally believe, based on some of the discussion here, completely dropping GCC is going to be cause more problems than it solves. Whatever the decision, the implementation should be well planned and deliberate.
I'm not so convinced. GCC does nothing, but slow us down.
That could be said about all backward-compatibility. A follow up question is, does it hold us back enough to justify breaking compatibility? It seems some people think yes, and others think no. We're at a stalemate, where no progress can be expected to take place. For things to move forward, either one side has to give in, or both sides can compromise and agree to a middle ground.