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

[Eli Zaretskii <eliz at gnu dot org>]

> Cc: markus.t.metzger@intel.com, gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Tue, 11 Oct 2016 17:24:09 +0100
> 
> On 10/11/2016 04:16 PM, Eli Zaretskii wrote:
> 
> > IMO, requiring to build GCC as a prerequisite for building GDB is a
> > major setback.  Building GDB is a relatively easy and straightforward
> > task today, even a native MS-Windows build.  By contrast, building GCC
> > requires quite a few additional prerequisites, which will also need to
> > be built correctly.  It also requires to configure the GCC being built
> > itself, which involves considering a large number of opt-in and
> > opt-out features, whose descriptions are not well suited for casual
> > users, and therefore whose consequences cannot be easily understood.
> 
> Windows may be one of the hardest systems on which to build GCC.
> For Unix systems, it's relatively painless.  It's easy to find scripts
> around the web that download the necessary dependencies and build gcc,
> all in one go.  I think the GCC source tree has contrib patches for
> at least the downloading part.

I take your word for it, as the last time I built GCC was a long time
ago.  I just know that I've read the latest GCC installation
instructions and found myself utterly confused wrt which options I did
or did not want/need.  Asking around didn't really help, because
everyone whom I asked basically told me "this is what I do, most of it
is taken from someone else before me".

Even if scripts are available that already have that decision figured
out, how is the user to know that decision is good for him/her?  You
don't build and install a compiler for a single job of building GDB,
you build it to make it your system compiler henceforth.  So this
decision, which options are and aren't needed is a serious one, and I
for one am unlikely to trust others with that decision (and have
trench stories to tell how not trusting them gave me a better package
than was available out there).

> > Yes, I use GCC, of course, but I just upgraded to 5.3.0 here a few
> > months ago, while you seem to be already talking about 6.x.  If we
> > start on this slippery slope, I can easily envision the requirement to
> > go up to 7.x very soon, exactly like switching to C++-compatible GDB
> > caused, within just few months,
> 
> That's a misunderstanding.  Full C++11 support is available
> in gcc 4.8 already.

Yes, I know.  I'm just envisioning that once we require to build GCC,
we will soon require a new enough version of it.  Like Joel says:

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

I see where it's going, and I don't like it.  We will make it hard on
users to build GDB.  Just 7 months ago all you needed was a C90
compiler, and look where we are now.

> I believe it's easy to find binary mingw gcc's of (at least) that
> vintage easily, for both mingw and mingw-64.

If we stay with 4.8 for long enough, I have no problem.  But we must
record this decision somewhere and stick to it, because otherwise it
will be one more domino to fall, and soon enough.

> I don't expect anyone to _have_ to build any mingw compiler to be able
> to build gdb for mingw.  

If you suddenly require 6.x or 7.x, they will have no choice.

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

How's above not requiring 6.x?  "Until someone writes a patch that
make gdb's build system enable C++11 support with gcc < 6" one must
have 6.x, or some code will not work or be unavailable for them,
right?  (And isn't there confusion between gnu++14 and C++11?)

> > a massive rewrite of GDB in complex C++.
> 
> Most of the changes have been around using std::string, destructors,
> and RAII, which are basic everyday C++ things.  The latter two are
> mainly about using compiler support for things we have to manually
> today (make_cleanup).   std::string just makes code shorter and safer,
> I don't see a real downside or anything complex about it.
> 
> A few patches that build supporting widgets will naturally use a
> bit more complex C++ internally, all in the name of making _users_ of
> such widgets significantly simpler.  This patch is one such example.
> These kinds of support patches naturally will need to come
> before we can make use of the features they add support for, so
> while it may appear we're going to keep adding lots of magic
> things, I don't think that's true.

Maybe you are 110% right; all I know is that these C++ surprises
started pouring on us with increasing rate without any prior
discussion, that's all.

But I don't want to argue about C++, that was just an example of a
slippery slope similar to what I fear will happen once we require a
new enough GCC to be able to compile GDB.  I think that would be a bad
mistake.