This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v5] don't keep a gdb-specific date
- From: Tom Tromey <tromey at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Hans-Peter Nilsson <hp at bitrange dot com>, gdb-patches at sourceware dot org
- Date: Tue, 25 Jun 2013 08:40:06 -0600
- Subject: Re: [PATCH v5] don't keep a gdb-specific date
- References: <1371835865-15879-1-git-send-email-tromey at redhat dot com> <871u7rwodv dot fsf at fleche dot redhat dot com> <20130624224138 dot GC5326 at adacore dot com> <alpine dot BSF dot 2 dot 02 dot 1306242048260 dot 69392 at arjuna dot pair dot com> <87y59ythcd dot fsf at fleche dot redhat dot com> <20130625142141 dot GF5326 at adacore dot com>
>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:
Tom> I think rather we have to back out the patch.
Tom> IIRC you can't really change the definition of modules like that.
Tom> sim using this file in gdb is an error, IMO, but not one I think is
Tom> worth a lot of effort to fix.
Tom> I'll prepare a reversion patch shortly.
Joel> How about duplicating version.in instead? The version number would
Joel> only need to be updated after creating the branch, and one extra file
Joel> every 3 months is not going to kill me.
I wonder what would happen if we added gdb/common/version.in to the sim
module definition. Maybe checkouts on old branches would just get a
warning instead of an error.
A quick experiment with an explicit checkout seems to confirm this.
So maybe this is salvageable after all.
I'm going to try updating CVSROOT/modules and then check out some old
branches, and see what happens. Please bear with me. I'll revert that
change if it causes a problem.
Tom