From: Ben Longbons <brlongbons@gmail.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb@sourceware.org
Subject: Re: [C++] System Requirements
Date: Sun, 15 Dec 2013 17:04:00 -0000 [thread overview]
Message-ID: <CA+XNFZNM2x6Gz4NNZPSYUiqE1nm-cOb+aVtRWWiuhJais60oOg@mail.gmail.com> (raw)
In-Reply-To: <20131215153129.GA27931@host2.jankratochvil.net>
On Sun, Dec 15, 2013 at 7:31 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> 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
next prev parent reply other threads:[~2013-12-15 17:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-14 0:34 Ben Longbons
2013-12-14 0:40 ` Ben Longbons
2013-12-15 12:28 ` Michael Veksler
2013-12-17 2:29 ` Andrew Pinski
2013-12-17 4:02 ` Ben Longbons
2013-12-18 12:47 ` Michael Veksler
2013-12-18 19:16 ` Ben Longbons
2013-12-15 15:31 ` Jan Kratochvil
2013-12-15 17:04 ` Ben Longbons [this message]
2013-12-15 19:53 ` Mark Kettenis
2013-12-16 13:03 ` Ivo Raisr
2013-12-16 13:52 ` Phi Debian
2013-12-17 5:35 ` Sergio Durigan Junior
2013-12-16 19:10 ` Eli Zaretskii
2013-12-16 20:09 ` Ben Longbons
2013-12-16 19:05 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+XNFZNM2x6Gz4NNZPSYUiqE1nm-cOb+aVtRWWiuhJais60oOg@mail.gmail.com \
--to=brlongbons@gmail.com \
--cc=gdb@sourceware.org \
--cc=jan.kratochvil@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox