From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18319 invoked by alias); 11 Jan 2009 04:19:34 -0000 Received: (qmail 18311 invoked by uid 22791); 11 Jan 2009 04:19:33 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 11 Jan 2009 04:18:57 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 3D1042A969C for ; Sat, 10 Jan 2009 23:18:56 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uPJ4YfasJnDY for ; Sat, 10 Jan 2009 23:18:56 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 738DB2A9694 for ; Sat, 10 Jan 2009 23:18:55 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 5291EE7ACD; Sun, 11 Jan 2009 08:18:48 +0400 (RET) Date: Sun, 11 Jan 2009 04:19:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: [RFA/win32] move win32_xfer_shared_library to (new) win32-tdep... Message-ID: <20090111041848.GQ24105@adacore.com> References: <20090110090843.GB29274@adacore.com> <20090110165031.GB24850@ednor.casa.cgf.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090110165031.GB24850@ednor.casa.cgf.cx> User-Agent: Mutt/1.4.2.2i 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/msg00237.txt.bz2 > >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. 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"? -- Joel