This is the mail archive of the
mailing list for the GCC project.
Re: The need for a libobjc maintainer
- From: "Timothy J. Wood" <tjw at omnigroup dot com>
- To: Ziemowit Laski <zlaski at apple dot com>
- Cc: Adam Fedor <fedor at doc dot com>, discuss-gnustep at gnu dot org, gcc list <gcc at gcc dot gnu dot org>, Andrew Pinski <pinskia at physics dot uc dot edu>, Nicola Pero <nicola at brainstorm dot co dot uk>
- Date: Fri, 31 Oct 2003 17:34:28 -0800
- Subject: Re: The need for a libobjc maintainer
On Friday, October 31, 2003, at 11:26 AM, Ziemowit Laski wrote:
Yes, absolutely. It would be good to have one maintainer who actually
lives on the GNU runtime day-to-day, and then another who has exposure
to the Darwin side of things (esp. differences between the GNU and
NeXT runtimes). So, if Nicola agrees to run for office :-), I'm
definitely for nominating both him and Andrew.
Just commenting as a very interested bystander, so feel free to
ignore me if I'm being an idiot, but ... it would be even better to
have a pair of maintainers, GNUstep and Darwin that were committed to
(a) LGPL-ing the Apple runtime (possibly dual license with APSL), (b)
merging the runtimes and (c) simplifying the objc compiler bits by
getting rid of the -ffoo-runtime switch.
I know this is probably wishful thinking on my part (backwards
compatibility, Apple legal issues, practical and philosophical
differences on whether __builtin_apply is better than assembly
messengers, runtime+crt0 initialization issues), but I can't help but
worry that the runtimes are going to continue diverging and maintenance
is only going to get harder.
A guy can dream, can't he? :)
I did some work a while back to take a MinGW release and the Darwin
ObjC runtime and get MinGW produce output for the Darwin runtime and
then modified the Darwin runtime to work on Win32/x86 (not too hard
since the x86 messenger code is already there). I know this is a very
small step in the grand scheme of things, but if anyone is interested
in the bits, I can put them up somewhere (they are fairly old at this
point, though much should remain the same).