[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Nikos Chantziaras
Subject: Re: [Mingw-cross-env-list] Qt built with mingw does not define Q_WS_WIN
Date: Sun, 28 Mar 2010 00:41:50 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100322 Thunderbird/3.0.3

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...

However, the Q_WS_WIN macro is not defined and compilation fails. I'm
trying to build the project with:


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]