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

[Simon Marchi <simon.marchi@polymtl.ca>]

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