Hi folks,
Here is another problem: we are currently defining the __WINE__ symbol to signal the headers that we are compiling Wine. This is fine. The problem that I'm facing is that there are apps (such as wxWindows) that want to know that they are _compiled_ (not run) under Wine. All platforms (and Wine is a platform, even if a virtual one) define standard symbols by default: __WIN32__, __MINGW32__, you name it.
There are valid reasons for a program to be able to test that is being compiled under Wine, and not under MinGW for example. Thus, we need to define a standard symbol, and __WINE__ seems to be the most appropriate. I think it's better to expose the prettier name, and use a longer/uglier one internally.
So, my proposal is: let's rename the __WINE__ symbol (as it's currently used) to something else (__WINESRC__, or whatever, suggestions welcome), once that's done, define __WINE__ when __WINESRC__ is not defined (the symbols would be mutually exclusive).
I can send in a patch if people don't object...
"Dimitrie O. Paun" dpaun@rogers.com wrote:
Here is another problem: we are currently defining the __WINE__ symbol to signal the headers that we are compiling Wine. This is fine. The problem that I'm facing is that there are apps (such as wxWindows) that want to know that they are _compiled_ (not run) under Wine. All platforms (and Wine is a platform, even if a virtual one) define standard symbols by default: __WIN32__, __MINGW32__, you name it.
Compiling under Wine should not IMO require defining additional symbols except probably __WIN32__.
There are valid reasons for a program to be able to test that is being compiled under Wine, and not under MinGW for example.
What are that reasons? Care to list some of them?
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.
Dimitrie O. Paun wrote:
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) :).
That works great in practice, but it will never fly in theory (anonymous).
Sh.
On Sun, 22 Dec 2002, Dimitrie O. Paun wrote: [...]
So, my proposal is: let's rename the __WINE__ symbol (as it's currently used) to something else (__WINESRC__, or whatever, suggestions welcome), once that's done, define __WINE__ when __WINESRC__ is not defined (the symbols would be mutually exclusive).
winemaker defines 'WINELIB'.
But I'm open to change, '__WINE__' looks more like the others. Maybe '__WINELIB__' would do? (but I prefer '__WINE__')
On December 22, 2002 03:04 pm, Francois Gouget wrote:
But I'm open to change, '__WINE__' looks more like the others. Maybe '__WINELIB__' would do? (but I prefer '__WINE__')
Alexandre, what do you think? I'd like to have winegcc define this by default, but we have to decide on a symbol name. Sorry to bug you with this now, but I'd like to get it out of the way so I can properly finish the wxWindows port.
"Dimitrie O. Paun" dpaun@rogers.com writes:
On December 22, 2002 03:04 pm, Francois Gouget wrote:
But I'm open to change, '__WINE__' looks more like the others. Maybe '__WINELIB__' would do? (but I prefer '__WINE__')
Alexandre, what do you think? I'd like to have winegcc define this by default, but we have to decide on a symbol name. Sorry to bug you with this now, but I'd like to get it out of the way so I can properly finish the wxWindows port.
I think __WINE__ is best, let's just rename the internal one. BTW this may be the occasion to clean things up a bit, we have way too many of these ifdefs in our headers, and many of them could be removed IMO.
On January 1, 2003 07:40 pm, Alexandre Julliard wrote:
I think __WINE__ is best, let's just rename the internal one. BTW this
Cool, but to what? __WINESRC__? __WINEBUILD__? __WINEINTERNAL__?
may be the occasion to clean things up a bit, we have way too many of these ifdefs in our headers, and many of them could be removed IMO.
Indeed. How do you want to do this? Can we do the rename, and then eliminate some of them? This would be best for me, since I can complete the work on wxWindows.
There are many things of this form:
include/mediaobj.h:#ifndef __WINE__ include/mediaobj.h-#include "rpc.h" include/mediaobj.h-#include "rpcndr.h" include/mediaobj.h-#ifndef COM_NO_WINDOWS_H include/mediaobj.h-#include "windows.h" include/mediaobj.h-#include "ole2.h" include/mediaobj.h-#endif include/mediaobj.h-#endif
Do you want to keep them?
"Dimitrie O. Paun" dpaun@rogers.com writes:
On January 1, 2003 07:40 pm, Alexandre Julliard wrote:
I think __WINE__ is best, let's just rename the internal one. BTW this
Cool, but to what? __WINESRC__? __WINEBUILD__? __WINEINTERNAL__?
It doesn't really matter, just pick the one you prefer.
Indeed. How do you want to do this? Can we do the rename, and then eliminate some of them? This would be best for me, since I can complete the work on wxWindows.
Sure, we can do the rename first.
There are many things of this form:
include/mediaobj.h:#ifndef __WINE__ include/mediaobj.h-#include "rpc.h" include/mediaobj.h-#include "rpcndr.h" include/mediaobj.h-#ifndef COM_NO_WINDOWS_H include/mediaobj.h-#include "windows.h" include/mediaobj.h-#include "ole2.h" include/mediaobj.h-#endif include/mediaobj.h-#endif
Do you want to keep them?
No, these should be removed. The same effect can be achieved by defining COM_NO_WINDOWS_H in the C files that use the include.
On January 2, 2003 12:30 pm, Alexandre Julliard wrote:
It doesn't really matter, just pick the one you prefer.
I know, but I was hoping people had better suggestions :) I like __WINESRC__ the best (but that doesn't mean much <g>), so unless people have a better idea, that's going to be it.
Sure, we can do the rename first.
Probably a script to do it would be best, no?
No, these should be removed. The same effect can be achieved by defining COM_NO_WINDOWS_H in the C files that use the include.
What about defining COM_NO_WINDOWS_H globally in Wine?
Dimitrie O. Paun wrote:
On January 2, 2003 12:30 pm, Alexandre Julliard wrote:
It doesn't really matter, just pick the one you prefer.
I know, but I was hoping people had better suggestions :) I like __WINESRC__ the best (but that doesn't mean much <g>), so unless people have a better idea, that's going to be it.
Not that this really matters, but what about __BUILDWINE__? Then #ifdef __BUILDWINE__ would seem to me to more clearly say "if we're building wine" Anyway I don't really mind but thought you deserved at least one suggestion in response to your plea...
David
-
Alexandre Julliard -
David Fraser -
Dimitrie O. Paun -
Dmitry Timoshkov -
Francois Gouget -
Shachar Shemesh