On Wed, Nov 20, 2019 at 5:54 AM David Chisnall <gnustep@theravensnest.org> wrote:
On 19/11/2019 23:28, Ivan Vučica wrote:
> On Tue, Nov 19, 2019 at 5:26 PM Jordan Schidlowsky
> <jordan@noodlecake.com <mailto:jordan@noodlecake.com>> wrote:
> > Is this not the strongest argument to deprecate GCC, and just build
> on Clang/LLVM? If feature parity with Apple's API is the goal, isn't
> this kind of a requirement at this point?
> >
> > There's other rather large projects moving purely to a llvm toolchain
> (android ndk), so it wouldn't be totally unheard of. They've deprecated
> gcc and are removing it entirely in a future release.
>
> Multiple compilers is still a good thing (even if one of them is worse
> than the others).
I agree in theory, but in effect the two compilers support entirely
different languages. The jump from the dialect of Objective-C that gcc
supports to the dialect that Clang supports is similar in terms of user
experience to the jump from C++98 to C++11. All of the C++ projects
that I work on have now switched (or are in the process of switching) to
depending on C++17, because it's a significant productivity boost.
Supporting GCC is not free. It adds cost to every single GNUstep
commit. You have to think about memory management, not just simple
ownership rules. You have to use macros instead of core language
features (such as fast enumeration). You can't use weak pointers. You
can't use blocks.
In addition to this fact, the API is becoming more and more dependent on blocks. Which means that, eventually, the GCC kludges which, at least, keep things compiling will no longer be able to support any of the more recent functionality. In my recent efforts to get Foundation/base closer to the existing version on Catalina this has become especially apparent.
If GNUstep had a large army of developers, I'd have no objections to
this. At the moment, GNUstep is severely under-resourced and time spent
supporting GCC is time not spent getting the core libraries up to parity
with a vaguely recent version of macOS.
Again, this is correct. If I were to estimate, out of the 6-8 weeks it took me to update libs-base, I spect about a total of 3 days figuring out issues related to blocks and how to declare them so that they would compile on gcc (using the macros we have) and work on clang.
Essentially what we have done is abstracted those features that are not supported on gcc so that they are compiled out in that case.
> GCC users can accept that not all applications will be compatible, if we
> can't implement APIs that depend on the "new" features.
Again, GCC users are not the only ones that are paying the cost. I did
a run with the ARC migration tool a while ago and around 2/3 of the
GNUstep source files could be automatically migrated, many of the
remainder needed only minor tweaks. Using modern Objective-C++ in the
core of GNUstep could significantly improve productivity. For example,
GSIMap is an implementation of a hash table using C macros. It is very
difficult to modify (I think I have broken something every time that
I've tried). Replacing this with a C++ template would be fairly simple
and would make it much easier to switch to other implementations as
required (there are a bunch of well-optimised C++ hash table
implementations with compatible interfaces tailored to different uses,
we could just pull half a dozen of them into the codebase and use them,
complete with type safety rather than a load of casts through void*)
Oh, and with ARC, all of the C++ implementations have correct memory
management for Objective-C, for free.
Yes, indeed. Something we don't have with GCC at all.
> But perhaps dropping GCC fully is too drastic.
>
> I have a similar opinion about some GUI backends; they're not very
> useful, but guide gnustep-gui and gnustep-back APIs to be more flexible
> and don't depend on just e.g. Cairo.
Again, this comes at a cost. For a long time (I'm not sure if this is
fixed now), Cairo was slow and flickery because it was being forced to
go via a double-buffering mechanism that was designed for libart.
Removing this without breaking the xlib and art back ends was nontrivial.
Even today, I believe the Cairo back end is still using the 'toy' font
APIs and not the ones that integrate with Harfbuzz, so we get quite poor
kerning with Cairo and miss some important features.
Indeed.
David
Yours, GC
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/