Re: [PATCH] Define GNULIB_NAMESPACE in unittests/string_view-selftests.c

Simon Marchi
2018-05-09T15:19:53Z

On 2018-05-09 09:49, Pedro Alves wrote:
> 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.

Ok, it's the part about wanting to use "using gnulib::..." that makes
the gdb namespace necessary that I had forgotten about. Either way
would be ok with me ("using gnulib::..." or using the namespace
explicitly at every call. They both have their advantages.

Like Joel, I'm fine with going ahead now.

Thanks,

Simon