This is the mail archive of the
mailing list for the GDB project.
Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0
- From: Stan Shebs <shebs at apple dot com>
- To: Keith Seitz <keiths at redhat dot com>
- Cc: Jim Ingham <jingham at apple dot com>, Andrew Cagney <ac131313 at redhat dot com>, gdb-patches at sources dot redhat dot com
- Date: Wed, 02 Oct 2002 10:21:20 -0700
- Subject: Re: [patch rfa:doco rfc:NEWS] mi1 -> mi2; rm mi0
- References: <Pine.LNX.firstname.lastname@example.org>
Keith Seitz wrote:
As far as the versioning thing goes, I must say that I don't really care,
(not that my opinion matters), but I can understand why some on this list
would be less sympathetic with objections to dropping mi0 coming from
Apple, who has done a lot of work on gdb and MI; no doubt fixed a lot of
stuff, but only managed to "submit" a giant distribution tarball of their
modified GDB. I wouldn't be too suprised if some thought that Apple was
taking advantage of the public's work. Mind you, I'm not saying that any
of this is true, but I wouldn't be suprised if some one reading this list
felt that way.
If you're saying it, then there are probably others thinking it, and
so I'll respond that this is both unfair and ignorant. Apple is the
only major system vendor using GCC and GDB as their primary development
tools, and we have a set of considerations not seen by GNU/Linux,
Cisco, HP, etc.
For instance, we have massive legacy, both from NeXT and from the old
MacOS world. We also have hundreds of fulltime engineers who can't
get their jobs done if GDB doesn't, say, display a thread local variable
correctly. We also have to provide tools for external developers coming
from the various existing Mac environments, such as MPW and CW, many of
them have expectations vastly different than what GNU traditionally
provides, and if you tell them "tough", then they stop developing for
the Mac, which is not acceptable.
I've dealt with this for a couple years in the GCC context, and the
situation is that even if we were to offer every single local change,
many of them would be turned down, which means that we always have a
constant overhead time to maintain our changes, depending on the churn
in FSF code. So when we have to deal with gratuitous change, that eats
into the time that could have been spent making patches for submission.
It's a real chicken-and-egg problem, and in the compiler group we've
been fortunate in having extra people to do some of this work while
still meeting our other obligations.
So let's all stay honest and aboveboard about what we're all doing and
why, and in turn not impugn the motives and activities of our
colleagues. We can accomplish a lot more working with rather than
against each other.