[Mesa-dev] [PATCH] Rename the DEBUG macro to MESA_DEBUG

[Jose Fonseca]

On 22/07/16 16:21, Emil Velikov wrote:
> On 22 July 2016 at 09:42, Christian König <deathsimple at vodafone.de> wrote:
>> Am 22.07.2016 um 03:37 schrieb Rob Clark:
>>>
>>> On Thu, Jul 21, 2016 at 9:35 PM, Rob Clark <robdclark at gmail.com> wrote:
>>>>
>>>> On Thu, Jul 21, 2016 at 1:48 PM, Vedran Miletić <vedran at miletic.net>
>>>> wrote:
>>>>>
>>>>> LLVM and Mesa both define the DEBUG macro in incompatible ways. As a
>>>>> general practice, we should avoid using such generic names when it is
>>>>> possible to do so.
>>>>>
>>>>> This patch renames all occurrences of the DEBUG macro to MESA_DEBUG,
>>>>> and removes workarounds previously used to enable building Mesa with
>>>>> LLVM (pop_macro() and push_macro() function calls).
>>>>>
>>>>> Please let me know if I missed any.
>>>>
>>>> I guess at least some in-flight patches (at least my
>>>> pipe_mutex_assert_locked() patch, but I guess DEBUG is common enough
>>>> that it might effect others).. not sure if there is a better way to
>>>> deal with that without things falling through the cracks..  maybe
>>>> introduce MESA_DEBUG which is the same as DEBUG first, and then a
>>>> later patch to remove DEBUG.  Or at least including sed/etc rule to
>>>> re-do the mass-change on a later baseline in the commit msg?
>>>>
>>>> I don't mind rebasing my patch, just more worried about things falling
>>>> through the cracks with other in-progress stuff, since it seems like
>>>> the end result would be a silent fail to enable intended debug code..
>>>
>>> btw, possibly tilting at windmills here, but afaik we don't export
>>> DEBUG outside the mesa codebase.. so actually it should be llvm that
>>> s/DEBUG/LLVM_DEBUG/
>>
>>
>> I already had the same issue with other libraries/headers as well which
>> define DEBUG as something.
>>
> Out of curiosity: can you give some examples ?
>
>> I clearly agree that those libraries shouldn't do that with such a common
>> name, but renaming the Mesa DEBUG define to something more library specific
>> would still be a good idea to avoid such problems in the future.
>>
>> So general approach is Acked-by: Christian König <christian.koenig at amd.com>
>>
> Note that doing this will likely break things for the VMWare people
> since (IIRC) on Windows/MSVC DEBUG is commonly used/set by the
> compiler.
>
> Jose can you confirm/dismiss if this will cause issues ?


We used to rely on DEBUG for Windows XP kernel drivers, but that's long 
gone (thankfully.)  It should be fine.


Jose