Re: Clang/LLVM migration roadmap

[Riccardo Mottola]

Hi,

sorry for being a little bit absent, day-job is overtaking, I skipped 
the meeting and had no energy to reply. Also, the words chosen 
irritated me and spoke to you guys separately.
Let me start with a reply on the facts given which here are then mixed 
with judgments which are personal of you and some others. So I just 
chime in writing the other side of the medal.
Also, as stated further in your newer thread "Clang migrati9on" is 
misleading, because the real goal is better ObjC-2 support, which can 
be achieved in different ways.

> 1) GCC lacks support for many memory management features that are 
> commonly
> used today
> 2) GCC's objective-c support is lagging behind and doesn't include 
> support
> for @[], @{}, @autorelease, etc etc etc
> 3) Lack of bug fixes in GCC's implementation of ObjC
> 4) GCC team does not consider ObjC release critical and will and HAS
> released with broken support for building ObjC targets.
> All of these things are UNACCEPTABLE

The GCC team has improved a lot support and you cite very old things 
that happened years ago. Amazingly, the  last several major releases 
of GCC up to gcc 11 have no issues. So while "legacy" the GCC setup is 
amazingly stable on all architectures I can test on (and I have many 
machines!). AlLso those bugs you cite do not show up
Furthermore those "modern features" do not significantly limit 
development and do not (almost?) impede using then in any 
applications, so the issue is mostly limited to "core".
I would scale them in as inconveniences, maybe serious, but not 
unacceptable.

GCC has its runtime, so its build system tests both together!

> 1) Currently, libobjc2 does not support some architectures and also 
> does
> not build easily on Windows under MSYS2.  While some older 
> architectures
> are, perhaps, not as important, building on Windows under MSYS2 is 
> critical.

The build setup of GCC is very consistent; the support is very vast 
and the runtime is essentially in C, supporting also architectures not 
explicitely tested or developed for.
GCC comes with its runtime, for the end user it means one consistent 
setup. Maybe it is installed by default in the system compiler (e.g. 
NetBSD!) or easily with a package (e.g. most Linux installations with 
GCC). On many system clang is shipped, but libobjc2 is either not 
shipped or unusable (e.g. FreeBSD!) which needs building it

In my opinion it would be unacceptable to drop many of these 
architectures. GNUstep caters to many people, several seek "off 
mainstream" users, running away from GNOME or such. The late Bernard 
who much spurred me in this project was for example a PPC user as 
myself.
GCC support on windows is good and I have a quite stable setup, the 
work on msys2 progressed well and appears to be stable on 32bit and 
64bit as the old gcc 3.4 setup was! Long go - many other setups 
appeared to work but were not production solid.


Debian and NetBSD support many architectures, several of them do not 
support clang well and especially do not have libobjc2 support.

> 2) GNUstep is an FSF project, so there is a political component if we 
> don't
> support GCC anymore.   This is not a show-stopper but is something to
> consider.
You do not consider it a show stopper, others may! Politics is a very 
personal thing. Politics/Ethics divides people! Just the license made 
people "camp" on GCC or CLang having distributions switch to one or 
the other (and then half-reconsidering the migration because of weak 
platform support ending with mixed setups for years!).
Because of politics we lost some members of this community.
Because of licenses and politics there are companies insisting using 
GCC and others CLang/LLVM! so...
Personally, I deem almost unaccebtale (to use your own words) to loose 
"the GNU compiler" since we are a GNU project. My ultimate goal is and 
remains to run GNU Emacs with GNUstep interface on GNU/Hurd running in 
a whole GNUstep session (GWorkspace, etc) and I am very close to it
For others, e.g. FreeBSD, the system compiler is Clang, so they just 
want to use that (as I am doing right now, typing this email! GNUMail 
with Clang 10.01 and libobjc2).


> 1) ARC
> 2) support for modern features in objc that are commonly used
> 3) more developers will be able to port their applications to GNUstep

All correct. Also, Clang is the default compiler on FreeBSD and the 
"almost de-facto" on OpenBSD too.

> Disadvantages
> --
> 1) libobjc2 is currently, as stated above, unstable or unsupported on 
> some
> architectures / operating systems.

Here, I add a list
1) libobjc2 does not support many platforms and it needs to be tested 
and enhanced on every OS+Arch separately. E.g. it works on x86 on 
Linux, but not on NetBSD
2) libobjc2 is separate from CLang, so while it the latter is widely 
used and supported, the runtime is mainly David's work. So while it is 
amazing what he achieved alone (kudos) it is essentially a one-man 
show, not much worse than the unsupported GCC one. Also, David 
interest in GNUstep itself dwindled
3) building libobcj2 does not use the standard autotools and 
gnustep-make setup - "high inconvenience"
4) building libobjc2 on windows does not work with the msys toolchain 
but requires  VS (for me "really unacceptable")
5) the whole configuration is fragile, often it does not link with the 
system linker, requires another linker which *may* not be even ready 
available
6) exception handling is fragile to get and i never get it working, so 
exceptions fall through to unhandled C++ stuff. Exceptions are also 
one of the major issues when porting a supported architecture to a new 
OS (e.g. NetBSD/x86)
7) libobjc2 seems slow. Even if David explained a lot of optimizations 
in memory usage, method calling.. when running GUI apps it feels 
inferior. This is a qualitative, not a quantitative judgment. Also, it 
could depend on clang vs gcc, not just the runtime.

> Approach
> --
> 1) make sure that libobjc2 is supported on as wide a range of 
> platforms as
> possible.
> 2) Fix issues with building on Windows/msys2

Agreed. I will work on it, I can devote more of my systems to 
CLang/libobjc2 if I have two samples of them if we want to work on it. 
I did that, but lack of progress with David had me switch to GCC back 
on systems where I planned to "check"

I also would find useful to try to fix the "libobjc2 replacement as 
GCC runtime" as it allows comparison, a gradual approach and also e.g. 
testing of 7) to a certain extent.

> We should make the transition as easy as possible for people who are
> currently using GCC to switch over to Clang/LLVM.

Given the above, for me it is hard to favour a switch, the loss is too 
big compared to the gain and uncertainity. But we can think of a more 
inclusive approach, perhaps. THere seem to me several roads open.

For me FOSS means freedom. Not "camp" on GCC or CLang. So the best 
final solution would be to support both compilers, even if accepting 
limitations when using one or the other. That frees us from politics 
and also ensures a better future.
Maybe in the 5 years Richard is thinking for the transition there will 
be a different panorama in the compilers? a new one? a dead one? Apple 
drops CLang? An unacceptable change in license (GPL4?) Who knows. As 
long as we are not bound 1:1 like Apple, we have future.

Riccardo

--
Proudly sent with GNUMail on GNUstep on FreeBSD/x86-64