From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2720 invoked by alias); 11 Jan 2009 04:24:57 -0000 Received: (qmail 2540 invoked by uid 22791); 11 Jan 2009 04:24:56 -0000 X-Spam-Check-By: sourceware.org Received: from pool-96-233-71-199.bstnma.fios.verizon.net (HELO cgf.cx) (96.233.71.199) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 11 Jan 2009 04:24:21 +0000 Received: from ednor.cgf.cx (ednor.casa.cgf.cx [192.168.187.5]) by cgf.cx (Postfix) with ESMTP id 6D79513C029; Sat, 10 Jan 2009 23:24:11 -0500 (EST) Received: by ednor.cgf.cx (Postfix, from userid 201) id 6D9982B385; Sat, 10 Jan 2009 23:24:11 -0500 (EST) Date: Sun, 11 Jan 2009 04:24:00 -0000 From: Christopher Faylor To: gdb-patches@sourceware.org, Joel Brobecker Subject: Re: [RFA/win32] move win32_xfer_shared_library to (new) win32-tdep... Message-ID: <20090111042411.GA8509@ednor.casa.cgf.cx> Mail-Followup-To: gdb-patches@sourceware.org, Joel Brobecker References: <20090110090843.GB29274@adacore.com> <20090110165031.GB24850@ednor.casa.cgf.cx> <20090111041848.GQ24105@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090111041848.GQ24105@adacore.com> User-Agent: Mutt/1.5.16 (2007-06-09) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-01/txt/msg00238.txt.bz2 On Sun, Jan 11, 2009 at 08:18:48AM +0400, Joel Brobecker wrote: >> >This patch moves the win32_xfer_shared_library function to a file >> >that is not specific to the target CPU. I introduced win32-tdep, >> >to follow the naming scheme used by win32-nat, even though these >> >file can also work on 64bit windows. >> >> If this file can work on 64 bit windows then it seems like it should be >> renamed to something more generic rather than potentially duplicating >> the same code in two places. >> >> Should win32-nat.c just be renamed to windows-nat.c? > >I think this would be a good idea. Same for win32-tdep. > >I suggest I commit the two remaining patches as is, and then do >the move as a separate step. That way, I don't have to rework >the patches after the move is done. That's fine. >In terms of the move itself, how do we want it to be done. >CVS doesn't support moves per se. Usually, in my own little CVS >repos where I don't use branches, I do a "mv" inside the CVS >repository. But I know that this brings its own problems. >Should we use "cvs remove + cvs add"? I don't know of any way to do a "mv" in CVS. If no one objects, I'll do some surgery on the CVS repository to make a copy of windows-nat.c and windows-tdep.c to make it look like they always existed and then I'll cvs delete the old files and change Makefile.in. cgf