Riccardo,
I don't believe that GNUstep should hold back features to remain compatible with any given compiler. Not implementing features that are widely used (not even particularly "modern" ones) because the less capable compiler (in this case the latest GCC) lacks support is not a healthy direction.
Like you, I believe in choice. I think that GNUstep should remain compatible with GCC so long as GCC is able to keep up with the features needed by the project.
It's really simple math. We are a team of limited man-power and, currently, there is no one on the time who has the time to do what needs to be done to implement the following in GCC:
1) Support for ARC properties (weak, strong, etc)
2) Syntactic sugar as I have specified in recent discussions
3) Internal compiler support for ARC (i.e. use the features in #1 to drive memory management)
4) Runtime changes to support the above
In LLVM/clang the above features already exist. What is missing is:
1) The ability of the runtime to work on a number of different platforms: (Windows, etc)
(if you can think of anything else that's missing, I'm sure you can think of something)
Who is going to write this code, you? (you already say your day job is taking over) Mine is as well very taxing. So the question remains, which one of the very few of us is going to take on these tasks. The path to get clang working is likely much shorter than GCC.
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 migration" is
misleading, because the real goal is better ObjC-2 support, which can
be achieved in different ways.
I ask again, who is going to have the time to do this?
> 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.
Okay, that's fine. I don't see it in the list above though. The fact remains that no one on the GCC team is willing or able to take the time to implement a single feature listed in either this list or the one above.
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".
Given that most of these modern features came out in 2006, I think it's time we stopped calling them "modern". Also, when you have a codebase that has been written within the last 16 years that uses these features, it is a major impediment to have to re-engineer your code to use an ancient version of Objective-C. The effort I am working on NOW in my day job is having to go through this very thing, and it's ridiculous in the extreme that this should have to be done.
I would scale them in as inconveniences, maybe serious, but not
unacceptable.
They are more than inconveniences.
GCC has its runtime, so its build system tests both together!
So what? To most developers who want useful software and just want their stuff to work this is meaningless.
> 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.
This is true. And this is possible to do under libobjc2 as well.
GCC comes with its runtime, for the end user it means one consistent
setup.
Again.. the "they come together" argument. Who cares whether clang and libobjc2 are packaged together so long as it works.
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
This is a good point and a lot easier to correct than updating the compiler and writing the runtime support as detailed above.
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.
And when they run to us they will find poor support for a version of the objective-c language which is verging on 16-17 years old. Do you think they will stay?
The late Bernard
who much spurred me in this project was for example a PPC user as
myself.
We should value architectures in accordance with the audience each has.
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.
The project I am on uses both clang and GCC in a production environment. Memory issues due to the lack of ARC and other workable solutions are a constant issue. In 2022 this is not something that we as a project should be particularly proud of.
Debian and NetBSD support many architectures, several of them do not
support clang well and especially do not have libobjc2 support.
Agreed. Again, this is something that should be addressed and represents less work than the work for GCC.
> 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...
Not so. Some people whom I have worked with have spent weeks trying to get memory issues solved when that time could have been spent doing more productive things and, indeed, saved money as well. I am wondering why you think that is a political concern.
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
As does libobjc. Just because something works on one architecture doesn't mean it will work on another.
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
Free software and open source is RARELY a one-man show.
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")
Correctable
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)
Agreed.
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.
I double you have any tests or numbers to back up the claim of it being slow.
> 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.
5 years seems to me to be an egregiously long time.
Riccardo
--
Proudly sent with GNUMail on GNUstep on FreeBSD/x86-64
GNUmail's only user. ;)