From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47047 invoked by alias); 11 Oct 2016 16:58:00 -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 47017 invoked by uid 89); 11 Oct 2016 16:57:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=stories, utterly, Until, henceforth 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 16:57:49 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bu0N6-0000aw-Lh for gdb-patches@sourceware.org; Tue, 11 Oct 2016 12:57:47 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40276) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bu0N6-0000ad-Hu; Tue, 11 Oct 2016 12:57:44 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1725 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bu0N4-0004Yr-JJ; Tue, 11 Oct 2016 12:57:43 -0400 Date: Tue, 11 Oct 2016 16:58:00 -0000 Message-Id: <83a8eadds7.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves CC: brobecker@adacore.com, markus.t.metzger@intel.com, gdb-patches@sourceware.org In-reply-to: (message from Pedro Alves on Tue, 11 Oct 2016 17:24:09 +0100) 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> <83insydifw.fsf@gnu.org> 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/msg00267.txt.bz2 > Cc: markus.t.metzger@intel.com, gdb-patches@sourceware.org > From: Pedro Alves > Date: Tue, 11 Oct 2016 17:24:09 +0100 > > On 10/11/2016 04:16 PM, Eli Zaretskii wrote: > > > 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. > > Windows may be one of the hardest systems on which to build GCC. > For Unix systems, it's relatively painless. It's easy to find scripts > around the web that download the necessary dependencies and build gcc, > all in one go. I think the GCC source tree has contrib patches for > at least the downloading part. I take your word for it, as the last time I built GCC was a long time ago. I just know that I've read the latest GCC installation instructions and found myself utterly confused wrt which options I did or did not want/need. Asking around didn't really help, because everyone whom I asked basically told me "this is what I do, most of it is taken from someone else before me". Even if scripts are available that already have that decision figured out, how is the user to know that decision is good for him/her? You don't build and install a compiler for a single job of building GDB, you build it to make it your system compiler henceforth. So this decision, which options are and aren't needed is a serious one, and I for one am unlikely to trust others with that decision (and have trench stories to tell how not trusting them gave me a better package than was available out there). > > 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, > > That's a misunderstanding. Full C++11 support is available > in gcc 4.8 already. Yes, I know. I'm just envisioning that once we require to build GCC, we will soon require a new enough version of it. Like Joel says: > 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. I see where it's going, and I don't like it. We will make it hard on users to build GDB. Just 7 months ago all you needed was a C90 compiler, and look where we are now. > I believe it's easy to find binary mingw gcc's of (at least) that > vintage easily, for both mingw and mingw-64. If we stay with 4.8 for long enough, I have no problem. But we must record this decision somewhere and stick to it, because otherwise it will be one more domino to fall, and soon enough. > I don't expect anyone to _have_ to build any mingw compiler to be able > to build gdb for mingw. If you suddenly require 6.x or 7.x, they will have no choice. > It's just that gcc 6.x is the first version that has switched > the _default_ mode for C++ to -std=gnu++14. So until someone writes a > patch that make gdb's build system enable C++11 support with gcc < 6, > then the C++11-only code in the gdb::unique_ptr patch that I'm proposing > will only be active with gcc 6.1 onward. But really I'm not > proposing to _require_ 6.x at all. How's above not requiring 6.x? "Until someone writes a patch that make gdb's build system enable C++11 support with gcc < 6" one must have 6.x, or some code will not work or be unavailable for them, right? (And isn't there confusion between gnu++14 and C++11?) > > a massive rewrite of GDB in complex C++. > > Most of the changes have been around using std::string, destructors, > and RAII, which are basic everyday C++ things. The latter two are > mainly about using compiler support for things we have to manually > today (make_cleanup). std::string just makes code shorter and safer, > I don't see a real downside or anything complex about it. > > A few patches that build supporting widgets will naturally use a > bit more complex C++ internally, all in the name of making _users_ of > such widgets significantly simpler. This patch is one such example. > These kinds of support patches naturally will need to come > before we can make use of the features they add support for, so > while it may appear we're going to keep adding lots of magic > things, I don't think that's true. Maybe you are 110% right; all I know is that these C++ surprises started pouring on us with increasing rate without any prior discussion, that's all. But I don't want to argue about C++, that was just an example of a slippery slope similar to what I fear will happen once we require a new enough GCC to be able to compile GDB. I think that would be a bad mistake.