From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4908 invoked by alias); 14 Sep 2010 17:50:34 -0000 Received: (qmail 4900 invoked by uid 22791); 14 Sep 2010 17:50:34 -0000 X-SWARE-Spam-Status: No, hits=-2.1 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; Tue, 14 Sep 2010 17:50:30 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 072712BAC28; Tue, 14 Sep 2010 13:50:29 -0400 (EDT) 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 rkQtE19++IuX; Tue, 14 Sep 2010 13:50:28 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id CB3A52BAC20; Tue, 14 Sep 2010 13:50:28 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 46FF0F599F; Tue, 14 Sep 2010 13:50:25 -0400 (EDT) Date: Tue, 14 Sep 2010 19:39:00 -0000 From: Joel Brobecker To: Pierre Muller Cc: gdb-patches@sourceware.org Subject: Re: [RFA 5/5] New patches to support --enable-targets=all for mingw64 Message-ID: <20100914175025.GI3845@adacore.com> References: <004201cb50f2$18d8f310$4a8ad930$@muller@ics-cnrs.unistra.fr> <20100913181100.GC3845@adacore.com> <000c01cb53e1$56476e60$02d64b20$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000c01cb53e1$56476e60$02d64b20$@muller@ics-cnrs.unistra.fr> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-09/txt/msg00271.txt.bz2 > But shouldn't we then clearly state that we drop hpux 10.X versions > support? We can. I don't think this is necessary, but Eli might think differently. In any case, it doesn't cost much to add a NEWS entry mentioning it. > Should we remove the function get_hpux_major_release completely, or > turn it into a function returning a variable, that could be set by > some command like "set hpux-major-release-version XX" that would > allow people using it on an old HPUX 10.X to still get old behavior? For a platform such as pa-hpux, I would do the strict minimum to make it work. I think you can just remove the function and assume version is 11 or higher. > Does anyone know of a good mailing list for HPUX developers to which > we could forward that question? It may sound harsh, but I personally think that the input from HP/UX developers in general is only of moderate interest to us. As long as no one steps up to the plate to support version 10.x of pa-hpux, we don't have the necessary means to do so. In fact, pa-hpux in general hasn't received much attention in the last few years. The only reason why I haven't discussed its removal is because I am still planning on contributing support for ia64-hpux, which should share a lot of code with pa-hpux support. My suggestion in this case is to KISS. If it turns out that this affects a developer who wants to upgrade to gdb-7.3, then we can think of alternative strategies, such as the one you suggested, and have him test it. Otherwise, the user should just stay with the older version of GDB. -- Joel