[PATCH] Revert "include: Use the ARRAY_SIZE() macro in debug.h."

[Andre Heider]

On 18/11/2018 22:32, Henri Verbeet wrote:
> On Mon, 19 Nov 2018 at 00:12, Andre Heider <a.heider at gmail.com> wrote:
>>>> Apart from the debug channels, we use these too: toupperW() (unicode.h)
>>>> wine_dlopen() (library.h), and I guess a few more.
>>>>
>>> Again, what are you doing exactly that you need those?
>>>
>>>> Are the specific reasons to not expose those useful functions to
>>>> external projects?
>>>>
>>> I'm sure we'd consider it if there was a demand for them. As it is
>>> though, there's no guarantee those won't go away between releases, or
>>> change in incompatible ways, etc. Depending on what you're using them
>>> for, chances are that you should either be using the official Win32
>>> APIs, or just be defining __WINESRC__. Perhaps you're doing something
>>> unusual enough that neither of those is an option, but in that case
>>> we'd be curious to learn more details.
>>
>> The result hopefully won't be unusual ;) This is about Gallium Nine. As
>> you might know, it's currently distributed as patches on top on wine. I
>> extracted the relevant code pieces into its own repository to make it a
>> standalone project, independent of wine - but built as a winelib project.
>>
>> That's why there're various uses of wine specific headers and functions.
>> But you made me dig up the reason for using those (it's not my code
>> base) - and I don't see one, heh. I could replace all the minor stuff
>> with either win32 or libc alternatives. The only thing left now is the
>> debug channel stuff.
>>
>> It would be nice if I could just use that too, but it shouldn't be too
>> much work to use something different. Maybe just plain old
>> OutputDebugString()?
>>
> It would probably make most sense to use the Mesa/Nine debug
> functions, although for something like Nine, I don't think simply
> defining __WINESRC__ would be all that bad. I think things like using
> ExtEscape() to get at winex11 internals are more problematic. (I
> suspect that could be avoided, but historically I don't think the Nine
> developers have been very excited to discuss that particular aspect;
> perhaps that has changed.)

I wasn't aware of that ExtEscape() issue, I'm just an independent guy 
that started to poke at nine recently. But I do care about clean code 
;), Was that issue discussed in the past? Any suggestions to get rid of 
this hack?