Re: MinGW build failure for GDB 8.2.90 with source-highlight

[Pedro Alves <palves at redhat dot com>]

On 03/07/2019 06:09 PM, Simon Marchi wrote:
> On 2019-03-07 12:11, Pedro Alves wrote:
>> On 03/07/2019 04:59 PM, Simon Marchi wrote:
>>
>>> I don't recall what's the long term solution for this.  We could use gnulib's namespace support [2], but the disadvantage is that we would need to use gnulib::some_function (assuming we name the namespace "gnulib") instead of just some_function to use the "fixed" version.  If we use some_function directly, it will use the buggy version on those systems where it is buggy.
>>
>> Wrap all of gdb in a namespace.  Recall that this was what led to C++
>> wildmatching support.
> 
> I don't understand how this will help.

Sorry, I thought the reference would make you recall
the previous discussions.  See below.

> If you have
> 
> #define open rpl_open
> 
> namespace gdb {
>   struct target_ops {
>     void open();
>   }
> }
> 
> The macro will still wrongfully replace open.

See slides #16-#17 of my Cauldron 2017 presentation:

 https://gcc.gnu.org/wiki/cauldron2017?action=AttachFile&do=view&target=gdb+-+C%2B%2B+conversion+%26+dogfood.pdf

The idea is to put all of gdb under "namespace gdb", and also put
gnulib in the same namespace, using gnulib's namespace support.
That way, there are no macros, and, the code looks just like it
does today, except for the "namespace gdb" wrapping.

Prototyped here:
 https://github.com/palves/gdb/commits/palves/cxx-gdb-namespace

Thanks,
Pedro Alves