This is the mail archive of the
mailing list for the GCC project.
Re: [objc-improvements] Merging back to mainline
- From: Alexander Malmberg <alexander at malmberg dot org>
- To: Ziemowit Laski <zlaski at apple dot com>
- Cc: discuss-gnustep at gnu dot org, gcc-patches at gcc dot gnu dot org, ronp at apple dot com, snaroff at apple dot com, Geoffrey Keating <geoffk at apple dot com>, Matt Austern <austern at apple dot com>, Stan Shebs <shebs at apple dot com>
- Date: Mon, 08 Sep 2003 16:43:52 +0200
- Subject: Re: [objc-improvements] Merging back to mainline
- References: <6C58F2CA-DFEB-11D7-8A28-00039390FFE2@apple.com>
Ziemowit Laski wrote:
> Having said that, though, I also believe that it is time that we
> separate concerns whenever possible. Since it is difficult to tell
> how long it would take us to resolve the issues we discovered, and/or
> whether we will discover still other issues along the way, I think
> that we should merge what we already have back to the mainline as
> soon as possible.
This seems reasonable, _if_ (and only if) the behavior is restored to
what it was in previous versions. If we're going to put off deciding
what to do about this, we must not make any changes now.
Are you interested in my patch (with the conflicting prototypes for a
receiver type made optional, and behavior restored to match previous
versions, aside from obvious bug fixes), or do you want me to try to get
my patch applied to mainline instead?
> The question that I have is therefore the following: Does the
> objc-improvements-branch, in its present shape, fail to build GNUStep
> or any associated apps or, if they do build, has their behavior
> changed in some erroneous way?
I don't think there are any known problems, but I haven't tested with a
clean version of the branch (without my patch) since the latest changes.
Once we've decided whether to restore the old behavior in the current
branch code, or with my patch, I can do a final round of testing.
> If the answer is yes, then we
> should definitely fix any remaining bugs before moving forward.
> But if the answer is no, I think we should go for the mainline merge.
> We really can't put this off any longer if we hope to get this stuff
> into the 3.4 release. Once the objc-improvements-branch fixes have
> made it into the mainline, we can continue addressing the remaining
Merging fixes is fine, but the branch seems to contain several other
changes, including some new extensions to the language. There are no
ChangeLog entries for these changes as far as I can tell, and I have not
found any information about them in the gcc mailing list archives. Thus,
I've asked before, and ask again:
What are the changes you want to merge to mainline? If, as it seems,
these include language extensions, how do these work from a user point
of view, and what is the rationale for adding them?
Until GNUstep and other objective-c users have had a chance to review
and discuss the changes, they cannot be merged to mainline, IMHO.
- Alexander Malmberg