I know that I likely start a flame war, but watching the discussion from an elevated point of view...
Yes. Taking three steps back (and upwards) from discussing the details of gcc vs. clang or its benefits. But looking on GNUstep as a project with goals, people etc.
> Am 25.11.2019 um 10:30 schrieb Gregory Casamento <greg.casamento@gmail.com>:
> * Compatibility, much of the API is moving towards using blocks. Blocks *ARE NOT SUPPORTED* on GCC and aren't likely to be anytime in the near future.
Hm, where has our own creativity gone?
Mine, personally, nowhere. I've been putting a great amount of work into this project as of late. Where should our creativity be spent? Bridging the gap between an old version of the language and it's successor or debugging and building new functionality in GS?
All of them. That is what made Apple and Cocoa a better and more stable development platform than other big OS I know of. And even is nowadays. There are methods deprecated in 10.2 still work in 10.14. So Apple did spend a lot of time not to break old software and that is superior to "just install a newer version of this and that - and live with that it breaks something unreleated". Unfortunately this attitude seems to have eroded.
Fred mentioned that it could be possible to define some block wrapper macros if some time is invested.
It that works out, we do not make our decisions depend on gcc *not* implementing something.
I have no problem with bridging the gap, but shall we continue to do so? Where can we draw the line? The only thing we are doing by constantly doing this is, as you said some time needs to be invested... is wasting time. We are delaying the inevitable.
Fred did talk about a weekend if I remember correctly. I do not know if it really can be done that quickly. But all other tasks and frameworks you want to do better once gcc is no longer supported take years...
So this argument for moving to clang looks more like an excuse that we do not work on our own gcc compatible solution, isn't it?
Given the list of things that I have mentioned as advantages, it's far from an excuse. I am simply advocating that we make things simpler for our developers and, potential contributors. Pretending or casting it as an "excuse" minimizes the weight of the argument without actually arguing the point.
|