Stefan, On Tue, Nov 26, 2019 at 4:18 PM Stefan Bidigaray <[email protected]> wrote:
> Hi Greg, > > On Tue, Nov 26, 2019 at 12:17 PM Gregory Casamento < > [email protected]> wrote: > >> >> Stefan, >> >> 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. > No worries. > On Tue, Nov 26, 2019 at 10:43 AM Stefan Bidigaray <[email protected]> >> wrote: >> >>> On Tue, Nov 26, 2019 at 4:55 AM Gregory Casamento < >>> [email protected]> wrote: >>> >>>> >>>> I'd really like some resolution on this topic. There seem to be a lot >>>> of reasons for and against. >>>> >>>> GC >>>> >>> >>> Hi Greg, >>> 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". >>> >> >> Indeed this is true. >> >> >>> 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. > Yes, and no. There are many new APIs which require blocks. Memory management could easily be done by ARC. Right now it is done manually, but look at it this way... base and gui can be used with both ARC and non-ARC programs due to this fact. Also CALL_BLOCK and DECLARE_BLOCK_* do not allow us to use block under GCC. They allow us a way to optionally declare them in a way that they can be compiled out in GCC and declared using clang. > > >> 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? > I believe earlier in this thread that David suggested that getting GCC up to spec with clang would take somewhere near 2 man years. My suggestion is, essentially, to get GCC to a more compatible position. > Indeed. If gcc had better support I wouldn't have a problem with it. 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? > I believe it does, but that is subjective. As the API evolves blocks and generics will become more and more ubiquitous. Generics are not that much of a concern as they are more about type-checking. Blocks are a big concern as they are being used as error and completion handlers everywhere in new APIs. For those who wish to remain in the past, this is not a problem, but unlike them I would like to retain GNUstep's relevancy. > 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. > Unfortunately, this seems to be where we ALWAYS are. At a stalemate and making no progress. Has anyone ever considered that connection to the past is what has held us back all this time? > Stefan >>> >> >> Yours, GC >> >> -- >> Gregory Casamento >> GNUstep Lead Developer / OLC, Principal Consultant >> http://www.gnustep.org - http://heronsperch.blogspot.com >> http://ind.ie/phoenix/ >> > > Stefan > >> Yours, GC -- Gregory Casamento GNUstep Lead Developer / OLC, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com http://ind.ie/phoenix/
