This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [C++] System Requirements

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:
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]