On 05/08/2018 09:47 PM, Simon Marchi wrote:
Could you remind me what's the link between putting gdb in its own
namespace and putting gnulib in its own namespace? How are they
related?
You can see the whole story in more detail in my C++ dogfooding talk
in last year's Caldron (around 11mins in), but the gist of it is
So late 2016 / early 2017 I looked at fixing this whole gnulib
issue with macros for good, by using gnulib's namespace support,
by putting:
#define GNULIB_NAMESPACE gnulib
in common/common-defs.h, and then fix up the whole tree.
The problem with that is you have to adjust _all_ calls to
functions that gnulib replaces, like e.g.:
- "printf" => "gnulib::printf"
- "fwrite" => "gnulib::fwrite"
And it's not a small number. After a lot of tedious hacking, I got
GDB to build on x86 GNU/Linux, see here:
https://github.com/palves/gdb/commits/palves/cxx-gnulib-namespace
Specifically:
https://github.com/palves/gdb/commit/bad0ab49ccc3c0de131bc6788da3703924d0903e
Note that patch has a detailed commit log as well, as I almost
posted it at the time. But then the ugliness of having to write
(and read!) "gnulib::" all over the place put me off more and more
and eventually I caved in and looked for a better idea -- some way
to avoid those explicit "gnulib::"s.
The alternative idea was to put _all_ of gdb in a namespace
instead.
I'd argue that that's a good thing on its own, but the
connection with gnulib is that while you can't do
using gnulib::printf;
at top level to avoid having to explicitly write the "gnulib::"
namespace throughout all the calls, because that would conflict with
the system's "printf" (it wouldn't compile), you can do that in
a namespace, like:
namespace gdb {
using gnulib::printf;
...
}
or simpler, just do:
#define GNULIB_NAMESPACE gdb
And with that, if all of gdb including the gnulib replacements are in
the same namespace then the calls to printf etc no longer need any
explicit "gnulib::" namespace qualifier, a plain "printf" call
calls "gdb::printf", etc.
That is the approach taken in the palves/cxx-gdb-namespace branch:
https://github.com/palves/gdb/compare/palves/cxx-gdb-namespace
The downside of putting all of gdb in a namespace is that
gdb becomes a little harder to debug, as you now must
prefix breakpoint locations with "gdb::", like:
(gdb) b gdb::internal_error
(gdb) b gdb::foo_bar
... and that's what led to last year's C++ wildmatching support,
"b -qualified", tab completion improvements, etc.
So I was waiting for gdb 8.1 (at least) to be out before proposing
moving all of gdb to a namespace, in order to give folks a little
time to get comfortable with the new features, and make it
reasonable to suggest that folks upgrade their top gdb to 8.1 (a
released version) instead of to git/trunk gdb if they want to gdb
a bit more conveniently. That's why I was wondering whether
now would be good time to propose moving forward with the
"namespace gdb" approach, since 8.1 has been out for a bit.