From: Daniel Jacobowitz <drow@false.org>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org
Subject: Re: generic code duplication in Ada files
Date: Tue, 29 Jan 2008 22:51:00 -0000 [thread overview]
Message-ID: <20080129224123.GA6586@caradoc.them.org> (raw)
In-Reply-To: <20080129223342.GH16288@adacore.com>
On Tue, Jan 29, 2008 at 02:33:42PM -0800, Joel Brobecker wrote:
> Daniel is a bit concerned by the code duplication that is occurring
> inside the Ada files (mostly ada-lang.c I believe). Because it's been
> the status quo for a while, Daniel didn't reject some patches I recently
> submitted, but I certainly heard his comments. Let me try to open up
> my mind a bit, and see if that might answer some of those concerns.
I came across angrier than I really felt, by the way. I apologize.
> We can make happen in the relatively near future. Doing it the other
> way will take, I am afraid, quite a bit of time. The cost of compromise
> is the semi-duplication that we have now. I can see that it can cause
> some maintenance trouble. But I promise in return that I will help
> in any way I can: fix the maintenance situations that might arise,
> and improve the situation in the long run.
This is exactly what I was hoping for. The duplication has been
status quo for many years; I don't mind it continuing that way, and
once we're in sync you'll have the option of doing restructuring on
the FSF tree, getting it right, and then importing it into your local
sources - much more palatable.
> Typically, my work-flow would involve doing the cleanup in the FSF
> tree, get it reviewed and checked in, and then push it to our tree.
> That way, I'm sure that any change I make finds its way to the FSF
> tree rapidly instead of sitting in our tree first, sometimes forever.
Hey, I hadn't even read this paragraph yet and I've already suggested
the same thing above! Great!
> So, any objection if I took advantage of the current status-quo for
> a little while longer? There are no more patches coming except
> the ones that are still under review, so we're close to the end
> of the tunnel.
And that's what I was going to ask. Also great. As long as the file
is not growing unboundedly, we're making progress :-)
Some of the things in Ada-specific code will be a mess to get into
common code, but IMO clearly worthwhile. For instance, a version of
symbol lookup which can return more than one symbol.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2008-01-29 22:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-29 22:41 Joel Brobecker
2008-01-29 22:51 ` Daniel Jacobowitz [this message]
2008-01-29 23:53 ` Paul Hilfinger
2008-01-30 11:39 ` Pierre Muller
2008-01-30 18:50 ` Joel Brobecker
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=20080129224123.GA6586@caradoc.them.org \
--to=drow@false.org \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/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