On Fri, Jul 22, 2016 at 4:39 AM, Vedran Miletić <ved...@miletic.net> wrote:
> On 07/22/2016 03:37 AM, Rob Clark wrote:
>>
>> On Thu, Jul 21, 2016 at 9:35 PM, Rob Clark <robdcl...@gmail.com> wrote:
>>>
>>> On Thu, Jul 21, 2016 at 1:48 PM, Vedran Miletić <ved...@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/
>>
>> 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.
well, I wouldn't expect both macros to exist at the same time
forever.. and it would let you avoid the flag-day patch. At any rate,
if the patch could be easily regenerated via sed or whatever, I guess
I'd be less concerned about that.
My main concern is that we silently lose some debug code.. for example
when backporting to release branches or rebasing work-in-progress
stuff, etc. Not sure there is a way to catch that other than
follow-up audits.
> 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.
yeah, hence the 'tilting at windmills' comment.. mostly just
grumbling about how llvm is kind of a pita as a dependency ;-)
BR,
-R
> Regards,
> Vedran
>
> --
> Vedran Miletić
> vedran.miletic.net
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
