David et al,
For all of the reasons listed in the previous email I am starting to wonder
about the viability of using GCC in the long run. As far as I can see it
the facts are these:
1. GCC does not support ARC, blocks and many other features which the API
is now using
2. Supporting GCC consumes more time due to having to work around these
features using awkward macros
3. The further clang's implementation and gcc's implementation of the
language drift apart, the more macros we will need to add
4. The work needed to add these features is monumental
5. We cannot depend on the GCC team to add these as they are more focused
on languages outside of ObjC.
The advantages to dropping GCC are as follows:
1. We can simplify the code drastically by removing any and all macros to
abstract the missing features
2. We can switch to using faster C++ or ObjC++ implementations of certain
functionality. TBD further.
3. We get ARC memory management for free.
4. Speeds up development since less time is spent on managing some of the
above.
Disadvantages to dropping GCC:
1. Political backlash from the FSF (possible, but unlikely there are
projects which use languages not supported by GCC)
2. Not able to support older hardware on which clang is unavailable and gcc
still is.
* We need to assess how critical supporting that hardware is.
3. Altering our "NetBSD" like philosophy where we can say "Of course
GNUstep will build on it."
Right now these lists are just food for thought. I am trying to start a
discussion about this, not making any final decisions yet.
Yours, GC
On Thu, Nov 21, 2019 at 6:02 AM Gregory Casamento <[email protected]>
wrote:
>
> David,
>
> On Wed, Nov 20, 2019 at 5:54 AM David Chisnall <[email protected]>
> wrote:
>
>> On 19/11/2019 23:28, Ivan Vučica wrote:
>> > On Tue, Nov 19, 2019 at 5:26 PM Jordan Schidlowsky
>> > <[email protected] <mailto:[email protected]>> 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/
>
--
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/
