Re: [PATCH 1/3] Introduce gdb::unique_ptr

[Pedro Alves <palves at redhat dot com>]

On 10/11/2016 09:47 PM, Eli Zaretskii wrote:
>> From: Pedro Alves <palves@redhat.com>
>> Date: Tue, 11 Oct 2016 20:19:14 +0100
>>
>>> Where are the rules and decisions that we won't?
>>
>> What sort of rules are you expecting?
> 
> What is the oldest version of GCC and C/C++ we are willing to support,

Please reread the whole thread...  That was _my_ question.

IMO, that should be decided based on what's the oldest version people
really care about _in practice_, and are willing to routinely test
and send fixes for.  Claiming we support gcc 3.4 and then not
testing it is pointless.  IMO, it'd be reasonable to say
we only make an effort to support gcc >= 4.8.  We have buildbots
testing that.

> and how many months/years from now we plan to reconsider that, for
> example.

I don't think this matters in practice.  We may reconsider every
week, and decide "no change" for 2 years.  Or reconsider every
2 years, and decide "change".  Same result.  I don't when or whether
in practice we'll stumble on some thing that it'd be
significantly easier to write if we required a newer compiler.
Time will tell.

> 
>>>>> If you suddenly require 6.x or 7.x, they will have no choice.
>>>>
>>>> Well, that's (an unintended, no doubt) strawman, because no one is
>>>> suggesting that.
>>>
>>> That's not how I read your messages.  Apologies for my
>>> misunderstanding, but I can show you how your words actually made that
>>> sound as if you were.
>>
>> Please do.  I'd love to learn to be clearer.
> 
> Joel:
> 
>> Agreed. Mostly, I was thinking of seeing if we can avoid the requirement
>> to build a GCC first, if all you are interested in is actually building
>> GDB. But, if C++11 is a much cleaner language overall, and its runtime
>> provides some nice additions, I think it makes better sense technically
>> to align ourselves to it. We've already made a huge requirement jump;
>> let's just do it right all the way. That increment doesn't seem all
>> that significant compared to requiring a C++ compiler.

(this was in context of building a new gdb on old systems
with no C++11 compiler available.)

> 
> You:
> 
>> It's just that gcc 6.x is the first version that has switched
>> the _default_ mode for C++ to -std=gnu++14.  So until someone writes a
>> patch that make gdb's build system enable C++11 support with gcc < 6,
>> then the C++11-only code in the gdb::unique_ptr patch that I'm proposing
>> will only be active with gcc 6.1 onward.  But really I'm not
>> proposing to _require_ 6.x at all.

I don't understand what's not clear here.    Conceptually,
the gdb::unique_ptr patch (this thread) does:

#if HAVE_STD_UNIQUE_PTR

// just use it

#else

// write replacement

#endif

The replacement is fully functional.

If I push the patch in now, HAVE_STD_UNIQUE_PTR will only be true
when compiling GDB with GCC >= 6.x, because G++ 6.1 targets G++14
by default, which is a superset of C++11.  The replacement
works with all other GCCs.  It'd be possible to make
HAVE_STD_UNIQUE_PTR be true with GCC >= 4.x too, but nobody wrote
that patch yet.

As Simon said, this is just like making use of some gnulib module
to make up for some missing bit in the system's C runtime.

I fail to see the worry here.  It's not like I'm proposing to only
enable some user-visible feature if GDB is built with some compiler
versions.

>> You yourself said that you have gcc 5.x available.  I don't really
>> understand why we're still arguing about this.
> 
> I'm still arguing because you all but decided to declare that to enjoy
> GDB to its fullest one has from now on to have GCC 6.x.  GCC 6.1 was
> released just this April, so it sounds too drastic to require it only
> a few months later.

Eli, I've repeatedly told you that that's completely false.  No one
is suggesting that.  At this point I have to wonder whether you're
not listening on purpose.  Please re-read the whole thread from the
top, including the series's intro.  It will be amply clear
that _the whole point of the patch_ is to keep supporting older
compilers.

Thanks,
Pedro Alves