From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5598 invoked by alias); 5 Feb 2006 04:48:08 -0000 Received: (qmail 5589 invoked by uid 22791); 5 Feb 2006 04:48:08 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 05 Feb 2006 04:48:07 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-198-179.inter.net.il [80.230.198.179]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id DMM55232 (AUTH halo1); Sun, 5 Feb 2006 06:47:59 +0200 (IST) Date: Sun, 05 Feb 2006 04:48:00 -0000 Message-Id: From: Eli Zaretskii To: gdb-patches@sourceware.org In-reply-to: <20060205002710.GC8728@trixie.casa.cgf.cx> (message from Christopher Faylor on Sat, 4 Feb 2006 19:27:10 -0500) Subject: Re: RFA: Support Windows extended error numbers in safe_strerror Reply-to: Eli Zaretskii References: <20060203215455.GA3501@nevyn.them.org> <200602032325.k13NPJ6g028001@elgar.sibelius.xs4all.nl> <20060203233935.GA13238@trixie.casa.cgf.cx> <20060205002710.GC8728@trixie.casa.cgf.cx> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00094.txt.bz2 > Date: Sat, 4 Feb 2006 19:27:10 -0500 > From: Christopher Faylor > > >Then perhaps we should create a new -nat.c file, say mingw-nat.c, and > >maintain it separately. (For that matter, I'd really love to see > >win32-nat.c be renamed to cygwin-nat.c, since that's what it really is > >going to be.) If neither Daniel nor Mark M. can afford becoming > >responsible maintainers for such a new native file, I volunteer to do > >my best to do that. > > > >Would you agree to such a solution? > > That is *exactly* what I expected to come out of this discussion. And, > I suspect that it won't just be win32-nat.c which will have to be changed. > There will be a header file or two, and probably some configuration magic. Whatever it takes, yes. > And, really, it is a bad design decision to have two different files > using the same debugging mechanism. If this was to be done right then > win32-nat.c should somehow be factored out further so that the common > bits can be shared. Cygwin and MinGW are alike enough that they should > share code. That would be going back to where you don't want to: to a maintenance burden on you, due to sharing code with MinGW. > I think Ulrich's point was that wasting time tinkering with code to make > it work better with non-POSIX platforms was counter-productive for > projects which are designed to run on same. I think Ulrich's point was that it would be waste of Ulrich's time to do what Ulrich doesn't want to do.