> Am 25.11.2019 um 11:44 schrieb Gregory Casamento <[email protected]>: > > Nikolaus, > > With respect... > > On Mon, Nov 25, 2019 at 5:18 AM H. Nikolaus Schaller <[email protected] > <mailto:[email protected]>> wrote: > I know that I likely start a flame war, but watching the discussion from an > elevated point of view... > > Elevated?
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 <[email protected] > > <mailto:[email protected]>>: > > * 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.
