This is the mail archive of the
mailing list for the GDB project.
Re: [C++] System Requirements
- From: Ben Longbons <brlongbons at gmail dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb at sourceware dot org
- Date: Sun, 15 Dec 2013 09:04:09 -0800
- Subject: Re: [C++] System Requirements
- Authentication-results: sourceware.org; auth=none
- References: <CA+XNFZO6-rhG_mnRtg_B_y6R3FaFRWzb_ED4G=Yf1gdNs4d+gw at mail dot gmail dot com> <20131215153129 dot GA27931 at host2 dot jankratochvil dot net>
On Sun, Dec 15, 2013 at 7:31 AM, Jan Kratochvil
> 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:
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