wine/ library/debug.c include/wine/library.h i ...

[Alexandre Julliard]

"Dimitrie O. Paun" <dpaun at rogers.com> writes:

> They'll most like have to do something like this anyway, with the only
> difference that the defines come after the include, but hey, it's a small
> price to pay! And if they don't like it, they don't need to use our headers
> at all, they can implement their own macros on top of the functions we export
> from ntdll. Come on, they are a few lines of code, is it really worth 
> complicating the Wine code for it?

Yes; if we make that API available then we have a responsibility to
try to make it usable for as many situations as possible, even if that
means some extra work for us. We can't simply use what's most
convenient for us and ignore the problems it will cause for others; if
we do that then we might as well not export the API at all.

So we need to find a compromise between convenience and uniqueness.
Clearly the TRACE etc. macros are not unique enough, we already have
had several conflicts with them, that's why we have the WINE_*
form. And for the other functions we need some kind of prefix too; not
necessarily "wine_dbgstr_" but I don't think "dbg_" is unique enough.

-- 
Alexandre Julliard
julliard at winehq.com