From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104899 invoked by alias); 9 May 2018 13:50:01 -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 104501 invoked by uid 89); 9 May 2018 13:50:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,LIKELY_SPAM_BODY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=years, talk X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 May 2018 13:50:00 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 74F9E11F955; Wed, 9 May 2018 13:49:58 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 49A5ED7B05; Wed, 9 May 2018 13:49:57 +0000 (UTC) Subject: Re: [PATCH] Define GNULIB_NAMESPACE in unittests/string_view-selftests.c To: Simon Marchi References: <1525382648-30186-1-git-send-email-simon.marchi@ericsson.com> <20180504165552.f4y7zcxzmgvwngel@adacore.com> <38335bd5-7e46-23e2-a45b-da970a1b8680@redhat.com> Cc: Joel Brobecker , Simon Marchi , gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Wed, 09 May 2018 13:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-05/txt/msg00193.txt.bz2 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. Thanks, Pedro Alves