On 2010-06-18 11:44+0200 Alexandre Julliard wrote:

"Alan W. Irwin" <ir...@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
__________________________


Reply via email to