From: richard@tiptree.demon.co.uk
To: Andrew Cagney <ac131313@redhat.com>
Cc: fedor@gnu.org, fnasser@redhat.com, msalter@redhat.com,
ezannoni@redhat.com, gdb-patches@sources.redhat.com,
Michael Elizabeth Chastain <mec@shout.net>
Subject: Re: [RFA] ObjC Testsuite
Date: Wed, 05 Mar 2003 06:15:00 -0000 [thread overview]
Message-ID: <D64EF6EA-4ED1-11D7-B9F8-00306544502E@tiptree.demon.co.uk> (raw)
In-Reply-To: <3E64BE1E.90407@redhat.com>
On Tuesday, March 4, 2003, at 02:54 pm, Andrew Cagney wrote:
>
>> I was getting increasingly worried that, while stuff is being
>> reviewed, none
>> of it actually seems to be getting into CVS ... even one of the
>> earliest patches
>> to simply add the existing objc code into the configure/make process
>> and
>> activate it (which I think one reviewer said was a no-brainer or
>> something
>> similar) is still outstanding.
>
> Just FYI, enabling the code for the default build is one of the last
> things to happen, not one of the first.
Thanks for the explanation, but I don't find it wholly compelling ...
> - gdb's language code isn't modula
> There isn't a clean way of dropping in new languages (like many
> things, a developer got half way through the process, and then
> stopped. It has then remained in that state for ~10 years. A
> --with-languages=... isn't there.
I understand that, yet it is the case that most of the objective-c code
has no effect except when debugging an objective-c program, so errors
which were not caught by the review process would only effect
objective-c developers, and frankly, for them it's probably better in
the CVS version of gdb to have partial/unreliable objective-c support
than no support at all. The patch I was referring to (Jan 3rd,
'Compile objc-lang.c objc-exp-tab.c') would seem to be safe.
I would have thought that the *main* point of the review process was to
ensure that any added code did not break existing code, so I assume
that the
objective-c support files in CVS at present are 'safe' (when enabled
they certainly don't seem to break things and I don't see why they
should), and
having patches in place in CVS as rapidly as possible would seem to
make it easier to review later patches ... but you may have found
different in practice.
> - this specific code came from [very old] a fork.
> As such it needs sigificant work before it gets integrated into GDB.
> Adam has been doing a briliant job. What's in GDB is noticably
> different to what was in Apple's fork.
Yes ... I did not intend to criticise/complain about Adams work ... I
was just offering to help any way I can, and trying to encourage an
efficient way of getting the work he's done into CVS quickly so he
doesn't have to do yet more work modifying his patches to cope with
changes in gdb.
Anyway, please don't feel compelled to waste time responding to this
... unless you have a suggestion for something I can do to help of
course.
next prev parent reply other threads:[~2003-03-05 6:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-03 16:15 Michael Elizabeth Chastain
2003-03-04 4:45 ` Adam Fedor
2003-03-04 6:42 ` richard
2003-03-04 14:54 ` Andrew Cagney
2003-03-05 6:15 ` richard [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-02-20 2:19 [RFA]: " Adam Fedor
2003-03-03 2:47 ` Elena Zannoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D64EF6EA-4ED1-11D7-B9F8-00306544502E@tiptree.demon.co.uk \
--to=richard@tiptree.demon.co.uk \
--cc=ac131313@redhat.com \
--cc=ezannoni@redhat.com \
--cc=fedor@gnu.org \
--cc=fnasser@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=mec@shout.net \
--cc=msalter@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox