On 2010-06-18 11:44+0200 Alexandre Julliard wrote:
"Alan W. Irwin" irwin@beluga.phys.uvic.ca writes:
Note also, my whole argument is based on the assumption that some standard means already exists for telling compilers running on Wine to #define __WINE__ at run time. However, if such standard means do not already exist there is no way I would want to ask for changes in any compilers (as you incorrectly imply later in your post), and again I would just live with it.
It sounds like you are confusing compile time and run time. The __WINE__ define can be used at compile time to detect the Wine build environment. If you are using a Windows compiler you have a Windows build environment, not a Wine one, so __WINE__ is not defined. That the Windows compiler is currently running under Wine is completely irrelevant.
If what you want is to add workarounds for Wine in your code, then neither __WINE__ nor the build platform matter. What matters is the platform your code is currently running on, which should be detected at run-time.
Excellent point. After my previous post, I thought some more about this whole issue, and if you detected Wine at compile time and built in different behaviour for that platform (say to work around a Wine issue), then that application could be potentially crippled on Microsoft Windows if you ran it there. I am pretty sure I would have gone on to the idea of run-time detection, but I hadn't done so yet so thanks for that!
Which leads to a Wine newbie question. What is the best way to detect the Wine platform at run time?
Finally, someone else in this thread mentioned this question has come up again and again to educate those like me who were making some incorrect assumptions about Wine platform identification. So perhaps a FAQ item on this subject would be appropriate?
Alan __________________________ Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________
Linux-powered Science __________________________