On 03.04.2017 13:06, David Chisnall wrote:
On 3 Apr 2017, at 11:51, Ivan Vučica <i...@vucica.net> wrote:
5.4 is almost a year old, so maybe this was fixed. However, I'm not sure it
would be so bad to have a workaround for this compiler?
There is already a warning that clang should be used (which I, of course,
switched to; I prefer it anyway). But having a workaround to make it work with
GCC, even in a basic, unsupported way, is probably still good?
As I said in the pull request, I’m hesitant to work around this for three
reasons:
- It’s a bug in GCC
- The work-around code requires using macros and loses type safety
- A runtime compiled with GCC lacks a number of important features
I think simply removing support for building with GCC is probably a better idea.
As I said in the pull request, I don't have any interest in GCC as an
Objective-C compiler anymore (hell, I haven't compiled a single line of
Objective-C code using gcc this year…). But I think outright dropping
GCC support is a bit harsh. You'd be turning up the heat a lot on
existing users of libobjc2 in gcc-based environments [0]. It would also
be a half-baked measure without removal of the legacy runtime API
(objc_msg_lookup() and friends). My favoured approach would be
deprecation of the old runtime API (and GCC support) in the next
release, and removal in the release after that.
Cheers,
Niels
--
[0] Even if you're stuck with manual reference counting etc., libobjc2
buys you a lot of good improvements, such as thread-safe +initialize…
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
