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.
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. I believe it's easy to find binary mingw
gcc's of (at least) that vintage easily, for both mingw and mingw-64.
mingw talks about gcc 4.8 binaries here:
http://www.mingw.org/wiki/howto_install_the_mingw_gcc_compiler_suite
I don't expect anyone to _have_ to build any mingw compiler to be able
to build gdb for mingw.
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.
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.