Re: __WINE__ vs. __WINESRC__
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
Re: __WINE__ vs. __WINESRC__
Dimitrie O. Paun [EMAIL PROTECTED] 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. -- Alexandre Julliard [EMAIL PROTECTED]
Re: __WINE__ vs. __WINESRC__
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? -- Dimi.
Re: __WINE__ vs. __WINESRC__
Dimitrie O. Paun [EMAIL PROTECTED] writes: Sure, we can do the rename first. Probably a script to do it would be best, no? I don't think there are that many, a patch would be fine. 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? That's a possibility too. I think I'd prefer to do it in the individual C files, but I haven't looked how many would need it, so maybe it's too much work (though Patrik can probably come up with a magic script to do it...) -- Alexandre Julliard [EMAIL PROTECTED]
Re: __WINE__ vs. __WINESRC__
Dimitrie O. Paun [EMAIL PROTECTED] 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. -- Alexandre Julliard [EMAIL PROTECTED]
Re: __WINE__ vs. __WINESRC__
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? -- Dimi.
Re: __WINE__ vs. __WINESRC__
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. -- Dimi.
Re: __WINE__ vs. __WINESRC__
Dimitrie O. Paun [EMAIL PROTECTED] 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? -- Dmitry.
Re: __WINE__ vs. __WINESRC__
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.
Re: __WINE__ vs. __WINESRC__
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.
Re: __WINE__ vs. __WINESRC__
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__') -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.
