From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75964 invoked by alias); 9 May 2018 15:19:53 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 75955 invoked by uid 89); 9 May 2018 15:19:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,LIKELY_SPAM_BODY,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.2 spammy=Specifically, years, talk, HContent-Transfer-Encoding:8bit X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 May 2018 15:19:51 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w49FJiLs007772 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 9 May 2018 11:19:49 -0400 Received: by simark.ca (Postfix, from userid 112) id 7BD951F217; Wed, 9 May 2018 11:19:44 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 8F3E91E56F; Wed, 9 May 2018 11:19:40 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 09 May 2018 15:19:00 -0000 From: Simon Marchi To: Pedro Alves Cc: Joel Brobecker , Simon Marchi , gdb-patches@sourceware.org Subject: Re: [PATCH] Define GNULIB_NAMESPACE in unittests/string_view-selftests.c In-Reply-To: References: <1525382648-30186-1-git-send-email-simon.marchi@ericsson.com> <20180504165552.f4y7zcxzmgvwngel@adacore.com> <38335bd5-7e46-23e2-a45b-da970a1b8680@redhat.com> Message-ID: <8934e52e7fe1e3463970c94589542de8@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 9 May 2018 15:19:44 +0000 X-IsSubscribed: yes X-SW-Source: 2018-05/txt/msg00199.txt.bz2 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