Re: Fix tui compilation with Solaris libcurses (PR tui/21482)

[Pedro Alves <palves@redhat.com>]

On 05/19/2017 02:20 PM, Eli Zaretskii wrote:
>> From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
>> Cc: gdb-patches@sourceware.org
>> Date: Fri, 19 May 2017 14:50:06 +0200
>>
>> I've checked in the cast part now.  Here's the NOMACROS part for
>> gdb_curses.h.  Tested as before on sparcv9-sun-solaris2.10 (curses) and
>> amd64-pc-solaris2.12 (ncurses).  Ok too?
> 
> I think this should be guarded by some OS-specific macro, so as not to
> affect other platforms, where the original problem doesn't exist. 

The problem exists, we just hadn't tripped on it yet.  
Googling around we see people running into curses defining "move" as
macro for instance, which conflicts with std::move.  

So I'd rather take the opposite approach.  GDB must be able to compile
with  NOMACROS defined on some hosts, so defining it everywhere makes
gdb behave the same everywhere and reduces the testing axis.  A patch
introducing a problem for Solaris or any host using the same curses
will be quickly exposed on any host.

> (I
> see 6 instances of these macros being tested in my ncurses headers,
> and I'm not on Solaris.)  Who knows what new problems this could cause?

I expect it'll fix more problems than create them.  Defining macros without
some sort of namespace prefix in C++ is a sure recipe for problems.
NOMACROS was surely invented to avoid these problems.

Thanks,
Pedro Alves