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

[Rob Clark]

On Tue, Jan 10, 2017 at 12:07 PM, Jan Vesely <jan.vesely at rutgers.edu> wrote:
> On Tue, 2017-01-10 at 16:43 +0000, Emil Velikov wrote:
>> On 10 January 2017 at 15:04, Vedran Miletić <vedran at miletic.net> wrote:
>> > On 09/19/2016 08:39 PM, Vedran Miletić wrote:
>> > > On 09/07/2016 06:52 PM, Vedran Miletić 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).
>> > > >
>> > > > v2:
>> > > >  * Rename remaining occurences found by git grep '\<DEBUG\>'
>> > > >  * Use /* !MESA_DEBUG */ with #else instead of /* MESA_DEBUG */
>> > > >
>> > > > Signed-off-by: Vedran Miletić <vedran at miletic.net>
>> > > > Acked-by: Christian König <christian.koenig at amd.com>
>> > > > ---
>> > >
>> > > Anyone?
>> > >
>> > > Regards,
>> > > Vedran
>> > >
>> >
>> > Emil and others,
>> >
>> > I can rebase this if there would be interest in getting it merged for 17.0.
>> >
>>
>> Thanks for the reminder.
>>
>> Not meaning to flock a dead horse - I'm rarely keen adding workarounds
>> and this looks like one.
>> Then again consider me neutral on the topic and I'll leave the final
>> call to Brian.
>
> if I may, I'd strongly argue _for_ this change. Using generic (non-
> prefixed) names is a bad idea.

generic names in *exported headers* are a bad idea.. otherwise we end
up with silliness like MESA_MAX2(), etc..

I'm generally of the opinion that we can change this if we have to, it
isn't really worth arguing against.  It does seem like a workaround
for problem in a dependency, rather than a problem in mesa.. but some
times that is what you have to do.

But wasn't it llvm that triggered this whole thing in the first place?
 If they are fixing, maybe we don't need the workaround?

Anyways, if it is still something that needs working around, and
someone wants to rebase the patch, go for it.

BR,
-R

> The same goes for LLVM/clang and there are corresponding patches to do
> that[0,1].
>
> Jan
>
> [0]https://reviews.llvm.org/D11833
> [1]https://reviews.llvm.org/D11834
>
>>
>> -Emil
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>