Re: [Mingw-cross-env-list] Qt built with mingw does not define Q_WS_WIN

[Nikos Chantziaras]

On 03/27/2010 11:54 PM, Mark Brand wrote:
> > After Qt was successfully built, I tried to build my Qt app with it. I
> > have code that needs to work different on Windows, and I check it with:
> >
> > #ifndef Q_WS_WIN
> > // Unix-only code...
> > #endif
> >
> > However, the Q_WS_WIN macro is not defined and compilation fails. I'm
> > trying to build the project with:
> >
> > i686-pc-mingw32-qmake
> > make
> >
> > This results in the following. Note that the definition of "memicmp"
> > is what Q_WS_WIN is needed for.
>
> It might make sense to check for MinGW since that that is what does or
> does not provide memicmp. It's not really specific to Qt.
>
> #ifdef __MINGW32__
>
> This raises the interesting question of whether Q_WS_WIN should be
> defined in Qt in mingw-cross-env. We have not missed it yet. The Qt
> documentation says about it only "Defined on Windows." What "on Windows"
> means is open to some interpretation, particularly when cross building.
> I don't know what the answer is.

There's only one interpretation: Q_WS_WIN is defined when building a 
Windows executable.  mingw builds Windows executables.  When a 
programmer checks for Q_WS_WIN, he/she does it in order to compile 
Windows-specific code into the application.  And that means code that 
should execute when the application is a Windows executable.

Checking for __MINGW32__ is not a good idea, since portable applications 
can be built with a multitude of compilers, and mingw happens to be just 
one of them.  You can't enforce something like this upon portable code, 
especially since there's already a way (Q_WS_*) for finding out the 
current build target.  Qt tries to provide a guaranteed way to 
programmers to check for the target platform by providing the Q_WS_* 
macros.  Breaking that guarantee also breaks Qt applications.

That is the reason I don't want to introduce checks for __MINGW32__ in 
my code.  Not for mingw, and also not for any other compiler out there. 
 If the only reliable way to create a Windows executable is to build 
with mingw32 under MS Windows, as I've done since now, then I'll have to 
continue doing it that way.

About memicmp: this function is deprecated anyway and I plan to remove 
it.  The problem about the wrongly defined Q_WS_* macros is more 
general.  I have many other places in the code that need to check for 
X11, Windows and OS X, some of them dealing with different guidelines as 
to how to present a GUI to the user.  It just happened that the memicmp 
check was the only one to trigger an error.  The rest would compile 
silently, but resulting in a Windows application that behaves like a 
Linux application, and that is more serious since it's silent without 
any errors involved.