|
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:1.9.1.8) 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... #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.
[Prev in Thread] | Current Thread | [Next in Thread] |