From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10991 invoked by alias); 5 Feb 2006 00:27:13 -0000 Received: (qmail 10982 invoked by uid 22791); 5 Feb 2006 00:27:12 -0000 X-Spam-Check-By: sourceware.org Received: from cgf.cx (HELO cgf.cx) (24.61.23.223) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 05 Feb 2006 00:27:12 +0000 Received: by cgf.cx (Postfix, from userid 201) id 11C2B13C0F8; Sat, 4 Feb 2006 19:27:10 -0500 (EST) Date: Sun, 05 Feb 2006 00:27:00 -0000 From: Christopher Faylor To: gdb-patches@sourceware.org Subject: Re: RFA: Support Windows extended error numbers in safe_strerror Message-ID: <20060205002710.GC8728@trixie.casa.cgf.cx> Mail-Followup-To: gdb-patches@sourceware.org References: <20060203215455.GA3501@nevyn.them.org> <200602032325.k13NPJ6g028001@elgar.sibelius.xs4all.nl> <20060203233935.GA13238@trixie.casa.cgf.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 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/msg00091.txt.bz2 On Sat, Feb 04, 2006 at 12:03:38PM +0200, Eli Zaretskii wrote: >> Date: Fri, 3 Feb 2006 18:39:35 -0500 >> From: Christopher Faylor >> >> The gist of the email is that I'm not happy having to support >> windows-specific workarounds in gdb while standing on my head in >> cygwin-land to make sure that as few workarounds as possible are needed >> for programs like gdb. > >Why do you guys always start important arguments while I'm asleep? ;-) > >> I'm concerned that the MinGW patches are going to eventually start >> encroaching on win32-nat.c (which we've already seen). I don't *want* >> to litter that file with any special non-cygwin accommodations. > >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. 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. However, that is, again, not something that I have any interest in doing. This is a personal preference and I'm afraid that it is very unlikely that anyone is going to convince me otherwise. >> So, I'm not sure what to do here. I agree with Mark, though (and with >> Ulrich Drepper when he made points about non-POSIX systems in his blog). > >I suggest we don't go there, and don't start arguing about Ulrich's >points (which I personally find deeply flawed). We don't need to >agree on ideology, as long as we find a good way of cooperating >towards common goals, a way that leaves everybody reasonably happy. > >After all, even I could drink beer with Ulrich when we met in Japan, >although our email relationship--how should I put it?--leaves a lot to >be desired ;-) 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. However, I'm not really interested in debating this either. I just mentioned it as an illustration of the fact that I have two problems with MinGW. One is a very strong personal preference to not have to worry about it in the part of gdb that I maintain and the other is a personal belief that the addition of accommodations for Windows in programs like gdb (or glibc) will prove to be detrimental to development in the long run. So, you might wear me down on the personal belief but it is extremely unlikely that anyone is going to change my personal preference. cgf