...meditations on an empty box with Windows 8...
By Konrad Rosenbaum, anno 2012 on the 31st day of December.
Since Qt 5.0.0 has been released a few days ago it seems prudent to move all my Qt4 based software over to the new version. Using Linux this is a comparatively easy port:
Qt5 gained a few dependencies over Qt4 - notably XCB (instead of plain old XLib and you now have to mention -xcb to the configure script or your programs refuse to show up on screen for lack of an output plugin) and ICU for Unicode support. The Building Qt 5 from Git page pretty much sums up what you have to do to get it to work.
Qt5 retains most of the API of Qt4, so porting your own programs is a simple matter of replacing a few obsolete method calls with new ones (most of my effort was to replace QString::toAscii() with QString::toLatin1()) and renaming a few method calls (e.g. QFileDialog::setFilter(const QString&) with QFileDialog::setNameFilter(const QString&) - which was a bit tricky, since Qt5 retains another QFileDialog::setFilter(QDir::Filters) method).
All-in-all I ported a project of 35000 lines of code within less than 3 hours with no particular hurry (I'm on vacation after all!). And without using any special tools (I would have created some scripts north of 4 hours).
So far I find that the port to Qt5 is well worth it. Not only will Qt4 not receive any new features, Qt5 also intoduces a few new features like QML and support for C++11 (the new C++ standard with such niceties as lambda-expressions or range-based loops).
So I will not spend any time on explaining how to compile/install Qt5 on Linux, since this is already sufficiently done in the Qt-Wiki. Drop me a note with specific questions if you think otherwise (you'll find my mail address at the bottom of this page)..
I will not spend any thoughts on MacOS either. Unless someone tells me how to compile Qt5 with a vanilla GCC 4.7 or an unmodified clang from the LLVM site (XCode 4.4/4.5 does not install on Snow Leopard, so all I have is an old Apple GCC 4.2, an unmodified GCC 4.7 that does not compile the Apple dialect of Objective C++ and a vanilla clang 3.2 whose libc++ does not want to compile).
Instead I'll focus on Windows, since it is well-supported, but a bit tricky to handle.
You have several compiler options on Windows, each one with their distinctive pros and cons:
MinGW/GCC has a few positives on its side: it is a platform independent compiler, so if you use it on Linux and Windows you will have to deal only with one compiler and its quirks. It produces decent code and has excellent support for C++11. If you write Open Source/Free Software you have absolutely no problems redistributing any DLLs that the compiler forces on you. Even if you write commercial/proprietary software you do not have any licensing problems, since the Runtime Exception of GCC allows you to distribute the runtime DLLs together with your own software under terms of your own choice (see the licenses/gcc/COPYING.RUNTIME file in your MinGW folder for details). It has the downside that WebKit does not work in Qt 5.0.0 - but this will be remedied in Qt 5.0.1 when the necessary patches are in. Another downside is that compiling with GCC on Windows is relatively slow: the version of make delivered with MinGW is not capable of using more than one CPU core (unless started from an MSys Shell) and GCC is quite slow on Windows (both GCC on Linux and MSVC on Windows are significantly faster).
All versions of MSVC have the advantage of producing faster code, but you will only notice this if you do computation heavy work in C++. A normal GUI application will not benefit from the more aggressive optimizations of MSVC. You will however notice the speed at which your own application compiles: it is much higher than with GCC, since MSVC is less demanding to a Windows file system (you should consider MSVC if Windows is your primary development workstation). They all have a major drawback for Open Source/Free Software (at least if you are using the GPL): you cannot ship the runtime DLL with your program, you have to hope it is there or ask your users to download and install the "MSVC redistibutable" themselves (see the GPL FAQ).
MSVC2010 makes it very easy for you to get started, just install the pre-compiled binary package and start Qt Creator, the remainder works as if by magic (once you have any version of MSVC2010 installed, even the Express edition will do). You can stop reading here if you can live with this option. I also recommend you use this option if you are new to Qt and are normally at home in Windows - use it for a while and proceed to other options once you have come up to speed or are bored enough to try something new.
MSVC2012 requires that you recompile Qt. The process is similar to compiling with MinGW, but you can use pre-compiled binaries for ICU and OpenSSL, or alternatively you need to make some minor adjustments to the compiling process described below.
A final note: you can install all of those in parallel. I run a virtual machine with Windows 8 that has two versions of MinGW (both 4.7, but 32bit and 64bit hosts+targets) and two versions of MSVC (2010 and 2012, both Express Editions) installed in relative harmony.
As an overview a comparison between the compiler options that you have:
| Feature | MinGW/GCC 4.7 | MSVC2010 | MSVC2012 |
| comes pre-compiled | no | only 32bit | no |
| can compile 32bit and 64bit | yes | yes | |
| can compile 32bit on 64bit system | yes | yes | |
| can compile 64bit on 32bit system | yes, but cross-compiling needs customizations | yes | |
| execution speed of programs | ok | great | |
| compiler speed | damn slow | high | |
| Qt 5.0.0 Webkit works | no | yes | |
| all other Qt 5.0.0 modules work | yes | yes | |
| C++11 support | good, almost complete | pretty bad | better, but still mediocre |
| can distribute runtime DLL with Open Source | yes | no | |
| can distribute runtime DLL with commercial software | yes | yes | |
Let's go with MinGW then. I recommend you still start by downloading and installing the pre-packaged Qt5 SDK. This way you'll have a working Qt-Creator and you can look at the MSVC2010 target to compare what it should like after installation in case of trouble (you can delete that directory later if you want to save a bit of space). Also one warning ahead: this experiment will require the installation of about a dozen packages (some of them quite large) and will require several GB of disk space (at least 13GB if you follow my recipe for just one target, 3GB more for the second target).
All of this will require a bit of very 'Unixy' fiddling that not all Windows users may feel up to - but, heck, you want to use MinGW instead of MSVC anyway! Right?
So here is my "recipe" for compiling Qt 5.0.0 yourself:
The compile process for Qt on MinGW only uses one CPU core. Sadly, since the cmd.exe shell of Windows does not have proper job control. So if you make two copies of the Qt sources and bother to compile two versions of icu and openssl you can do a 32bit and 64bit compile of Qt in parallel - they just must not touch the same directories at the same time, otherwise it is quite reasonable.
Once the compile is under way: take the day off, see you kids or parents - have a nice day and check back a few hours later. I left my computer compiling all evening and throughout the night - it took at least 6 hours, possibly lots more.
Never ever compile on a network drive! It will take weeks instead of hours! GCC is very I/O-intensive (it reads and writes files in small chunks) and Windows is (still) very stupid about I/O optimizations. GCC assumes an optimized file system layer in the underlying OS - a Linux kernel will easily optimize by reading ahead for the next few lines that GCC will want to read and buffer data that GCC wants to write until it has collected enough to warrant looking for the right sector on the disk. Windows is still the only Desktop/Server system that does not have a proper file system cache - even in Windows 8 and after dozens of other systems have shown how to do it for decades.
You can easily support two versions of MinGW by creating a little batch file to initialize your environment, for example this is what I use for my 32bit environment (D: is my projects disk, this file is D:\mingw32\DevEnv.bat):
@echo off rem above: switch command echo off to be less annoying echo Initializing MinGW 32bit Environment. rem Ruby is needed for some Qt configuration rem ...also Python and ActivePerl rem ...which are normally already in PATH rem for normal development it would not hurt rem to leave them out of PATH though... set PATH=c:\Ruby193\bin;%PATH% rem ICU and OpenSSL for features set PATH=d:\openssl-x86\bin;d:\icu32\bin;d:\icu32\lib;%PATH% rem MinGW and Qt itself... set PATH=d:\mingw32\bin;d:\Qt5.0.0\mingw32\bin;%PATH% rem output for comparison echo PATH: %PATH% rem go to my development directory d: cd\ rem done: go back to normal shell mode echo Ready. @echo onYou then link this file with a shortcut to the target %comspec% /k ""D:\mingw32\DevEnv.bat"" - this will start a version of cmd.exe that initializes itself with this batch file and then becomes interactive. The "set PATH" lines extend the PATH variable to include all directories that contain executables and DLLs that I normally need to compile Qt5 programs (in this case for 32bits) - make sure you use the right ones for the kind of target you want (clean 32bit or clean 64bit).