From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97584 invoked by alias); 11 Oct 2016 15:17:23 -0000 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 Received: (qmail 97571 invoked by uid 89); 11 Oct 2016 15:17:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_05,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=optout, opt-out, suited, bottle X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 11 Oct 2016 15:17:12 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btyni-0003CD-Ti for gdb-patches@sourceware.org; Tue, 11 Oct 2016 11:17:10 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38892) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btyni-0003Be-Px; Tue, 11 Oct 2016 11:17:06 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1609 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1btyng-0002xS-Sr; Tue, 11 Oct 2016 11:17:05 -0400 Date: Tue, 11 Oct 2016 15:17:00 -0000 Message-Id: <83insydifw.fsf@gnu.org> From: Eli Zaretskii To: Joel Brobecker CC: palves@redhat.com, markus.t.metzger@intel.com, gdb-patches@sourceware.org In-reply-to: <20161011144741.GF3813@adacore.com> (message from Joel Brobecker on Tue, 11 Oct 2016 07:47:41 -0700) Subject: Re: [PATCH 1/3] Introduce gdb::unique_ptr Reply-to: Eli Zaretskii References: <1476117992-5689-1-git-send-email-palves@redhat.com> <1476117992-5689-2-git-send-email-palves@redhat.com> <20161011121639.GE3813@adacore.com> <68fc02cb-59bc-012c-d1be-b5ed2076d6a5@redhat.com> <20161011144741.GF3813@adacore.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2016-10/txt/msg00260.txt.bz2 > Date: Tue, 11 Oct 2016 07:47:41 -0700 > From: Joel Brobecker > Cc: "Metzger, Markus T" , "gdb-patches@sourceware.org" > > > I think we're pretty much down to not-that-exotic hosts nowadays. > > At least, all hosts there seem to me like should have working > > gcc or clang ports. > > Agreed. Mostly, I was thinking of seeing if we can avoid the requirement > to build a GCC first, if all you are interested in is actually building > GDB. But, if C++11 is a much cleaner language overall, and its runtime > provides some nice additions, I think it makes better sense technically > to align ourselves to it. We've already made a huge requirement jump; > let's just do it right all the way. That increment doesn't seem all > that significant compared to requiring a C++ compiler. IMO, requiring to build GCC as a prerequisite for building GDB is a major setback. Building GDB is a relatively easy and straightforward task today, even a native MS-Windows build. By contrast, building GCC requires quite a few additional prerequisites, which will also need to be built correctly. It also requires to configure the GCC being built itself, which involves considering a large number of opt-in and opt-out features, whose descriptions are not well suited for casual users, and therefore whose consequences cannot be easily understood. Please don't do that. As someone who builds GDB since v7.4 (and offers it for other MinGW users as prebuilt binary package), such a requirement will be a death blow for me, because building GCC on MS-Windows is even more complicated than doing that on Posix platforms. Yes, I use GCC, of course, but I just upgraded to 5.3.0 here a few months ago, while you seem to be already talking about 6.x. If we start on this slippery slope, I can easily envision the requirement to go up to 7.x very soon, exactly like switching to C++-compatible GDB caused, within just few months, a massive rewrite of GDB in complex C++, something that IMO was never planned or discussed before actually doing it. It's only natural: one out of the bottle, no genie can be constrained anymore. So please let's not start on this slippery slope. Let's continue requiring only the standards that are widely available with the compiler versions out there, which in practice means we should always support GCC versions from at least 5 years ago, and at least 2 major releases ago. I don't expect my request to be honored, or even considered seriously. But I cannot let this pass without voicing my very strong opposition to such a requirement.