From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31806 invoked by alias); 15 Dec 2013 17:04:15 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 31796 invoked by uid 89); 15 Dec 2013 17:04:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-we0-f172.google.com Received: from mail-we0-f172.google.com (HELO mail-we0-f172.google.com) (74.125.82.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sun, 15 Dec 2013 17:04:13 +0000 Received: by mail-we0-f172.google.com with SMTP id w62so3755174wes.3 for ; Sun, 15 Dec 2013 09:04:10 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.37.112 with SMTP id x16mr10577155wij.48.1387127050025; Sun, 15 Dec 2013 09:04:10 -0800 (PST) Received: by 10.216.236.71 with HTTP; Sun, 15 Dec 2013 09:04:09 -0800 (PST) In-Reply-To: <20131215153129.GA27931@host2.jankratochvil.net> References: <20131215153129.GA27931@host2.jankratochvil.net> Date: Sun, 15 Dec 2013 17:04:00 -0000 Message-ID: Subject: Re: [C++] System Requirements From: Ben Longbons To: Jan Kratochvil Cc: gdb@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2013-12/txt/msg00026.txt.bz2 On Sun, Dec 15, 2013 at 7:31 AM, Jan Kratochvil wrote: > On Sat, 14 Dec 2013 01:34:17 +0100, Ben Longbons wrote: >> We have already seen the kind of trouble it takes to support old >> systems with Python 2.4 > > Python 2.4 has been recently decided to be discontinued: > https://sourceware.org/ml/gdb-patches/2013-12/msg00402.html Ah, good to hear! But even though it's an optional feature, it highlights the kind of problem we face with older dependency versions. >> I propose that the minimum "development requirements" is either gcc >> 4.6 or 4.7. > > I find it too strict for GDB even myself, for example RHEL-5 with gcc-4.1 > still should be able to build upstream GDB even in some restricted form (such > as without the Python mentioned above). "some restricted form" would be what I call "deploy requirements", and would be enough to enable all user-visible features. The "develop requirements" would only be what's necessary to enable all the compiler warnings, ensure easy debugging, etc. Personally, I don't get why people who are using long-term "stable" releases expect to be able to use the latest and greatest version of anything. If you only need to *use* gdb, you can just stick to older versions (including 7.7) which are still fully-featured releases. But you're saying you're using RHEL5 for your *development* ? I'm not used to developers who can even stand not using the latest release. To quote one of my covolunteers, who uses frankendebian: "I think the main reason I run a lot of testing packages is I don't want to be left behind tech-wise because my favorite distro is lagging. I need to be on top of the latest&greatest so I can find my clients the best possible solutions to their problems." Regardless of where we set the bounds, do you agree to the *concept* of having two different modes? > There are enough benefits even just with C++03. C++11 etc. extensions still > can be done incrementally in the future. For example, one of the major motivations of switching to C++ is to use exceptions. And exceptions are hard to use properly without move constructors (yes, compile-time "noexcept" propogation is only in gcc 4.6, but it is quite rare that you need to *prove* it to the compiler ... but that can be done in "development mode" anyway). And C++11 is, in many ways, a whole new language. The way you write APIs when you have moves is completely different than the way you write APIs without moves. And I'm *sure* you know that any "temporary hack until we're allowed to use rvalue references" will survive for decades. -Ben