__WINE__ vs. __WINESRC__

[Dimitrie O. Paun]

On December 22, 2002 04:44 am, Dmitry Timoshkov wrote:
> Compiling under Wine should not IMO require defining additional symbols
> except probably __WIN32__.

It shouldn't. In theory. But the difference between practice and theory
is that while in theory practice and theory are the same, in practice
they are different ((c) Larry McVoy) :).

For example, they may test for it to work around bugs in Wine. Yeah, Wine
shouldn't have bugs, but it does, and will continue to do so for the 
forseeable future. Yes, they should submit a patch instead, but they are
3rd party apps, they can't wait for the change to propagate to all users.
Just like we asked for -fshort-char in gcc, but we can't assume all gccs
out there support it the moment it got into the gcc tree. Or they may want
to use glibc functions not available on MinGW. And so on.

Of course, you will say, all these are better served by a configure script,
and I agree with you. But this is _their_ project, not ours to decide how
they do it. Some don't even have a configure script, and it may be way easier
for them to add 1-2 #ifdefs than to completely change their build to port
to Wine. Some may be libraries (e.g. wxWindows) that don't want their headers
to depend on configure scripts, just like we don't want ours, because they
will be used by 3rd party apps and they don't want to force them to have a
configure script (as we shouldn't force our users).

But all this is irrelevant: current practice is to define a standard symbol
to mark the platform. Unless we have overriding concerns (and I can't see
any, defining a symbol that we don't test for in Wine is a noop), we should
do the same. It is the user's prerogative to make use of it as they see fit.

-- 
Dimi.