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

Vedran Miletić vedran at miletic.net
Fri Jul 22 08:39:33 UTC 2016

On 07/22/2016 03:37 AM, Rob Clark wrote:
> 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
> BR,
> -R

Regarding in-flight patches, I did this change manually ("it can't be 
that hard, right, there's just a bunch of them") but I suppose it could 
be scripted and I would prefer this approach to having both macros at 
the same time.

Regarding s/DEBUG/LLVM_DEBUG/, I understand the reasoning and agree that 
ideally LLVM should rename the macro and not export macros with generic 
names. However, to avoid potential future conflicts, Mesa should use 
non-generic macro names anyhow.


Vedran Miletić

More information about the mesa-dev mailing list