Re: [C++] System Requirements
Ben Longbons <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <CA+XNFZNM2x6Gz4NNZPSYUiqE1nm-cOb+aVtRWWiuhJais60oOg@mail.gmail.com> |
On Sun, Dec 15, 2013 at 7:31 AM, Jan Kratochvil <[email protected]> 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