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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.