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

[Alexandre Julliard]

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

> Granted. But there is a fundamental difference: all other wine_* functions
> are so esoteric and rarely used, that we could even call them
> wine_esoteric_function_... and no one would be bothered by it :)

It's not only the wine_* functions. There is no conceptual difference
between code that resides in a dll inside the Wine tree and code in a
Winelib dll outside the Wine tree. You can happily copy code back and
forth between Wine and the Winelib app, and you expect it to
work. That's the principle of least suprise again <g>

> Obviously, if people are going to use our interface, they are not going
> to use our long names directly. Why not allow them the option of using
> our short names? How many apps are going to have a TRACE macro _if_ they
> decide to use our debugging API? And if they do, they can -DWINE_NO_SHORT_DBG_API
> and be done with it (or we can enable it only if -DWINE_SHORT_DBG_API).

I'm not opposed to a define to export the TRACE/FIXME/ERR/WARN macros,
but that's not a general solution. We don't want to have to explain
"sure the API is broken but if you define this magic symbol you can
make it sane again". We should define a sane API in the first place.

-- 
Alexandre Julliard
julliard at winehq.com