I am trying to statically build Qt using Visual Studio 2013
To do so, I'm following the instructions provided by the official website
1) ActivePerl 5.20 is downloaded, installed and added to the PATH.
2) The archive for qt-everywhere-enterprise-src-5.3.1 is downloaded and unzipped in C:\Qt\Entreprise_2
3) I open msvc 2013 command prompt, and change directory to: C:\Qt\Entreprise_2\qt-everywhere-enterprise-src-5.3.1
4) From here, I add 2 new elements to the path:
SET PATH=C:\Qt\Entreprise_2\qt-everywhere-enterprise-src-5.3.1\qtbase\bin;C:\Qt\Entreprise_2\qt-everywhere-enterprise-src-5.3.1\gnuwin32\bin;%PATH%
5) I define the QMAKESPEC in order to use msvc: SET QMAKESPEC=win32-msvc2013.
6) finally, I launch the compilation:
configure -commercial -nomake tests -nomake examples -debug -static
If I skip part 5), I instead receive the
I receive the answer:
"QMAKESPEC environment variable is set to "win32-msvc2013" which is not a supported platform"
If I skip step 6, I obtain instead:
"Unable to detect the platform from environment. Use -platform commandlineargument or set the QMAKESPEC environment variable and run configure again"
However, according to Qt support center:
1) "win32-msvc2013" is the correct QMAKESPEC to use with Visual Studio
2) If we use Visual Studio Command prompt (as I did) instead of the normal one, setting QMAKESPEC is optionnal anywey, as visual studio is supposed to set the correct parameters at the beginning
So, does anyone have any idea about how I could resolve these errors?
Incidentally does anyone knows what defines a Qmakespec as corresponding to a "supported platform"?
Had the same problem, first go look in the mkspecs folder (from the archive) and make sure your platform is there, might not be supported or look here:
http://doc.qt.io/QtSupportedPlatforms/index.html
If your platform is supported and you have it in your extracted mkspecs folder, then no clue what your problem is?!?
Apparently, a good part of the files inside the mkspec folder either failed to copy when I extracted the archive, or were destroyed afterward. Most likely the latter, as it would appears that every time I try to launch a compilation some source file are erased.
The solution I found is to recreate the source file from the archive before every compilation.
Related
The library mylib consists of the library proper, in directory lib/, and a test suite, in directory test/. It is completely under CMake control:
mylib/CMakeLists.txt:
...
add_subdirectory(lib)
add_subdirectory(test)
...
mylib/lib/CMakeLists.txt:
...
add_library(my_lib ${src_files})
...
mylib/test/CMakeLists.txt:
...
add_executable(mytest mytest.c)
target_link_libraries(mytest mylib)
Build steps are:
mkdir build
cd build
cmake ..
make
ctest # or make test
make install
Works under Linux, stable since many years. Under Windows10 though, a message window pops up, entitled "mytest.exe - System error": "The code execution cannot proceed because mylib.dll was not found. Reinstalling the program may fix this problem."
No, installing (rather than reinstalling) would not be a good solution: I need to first test the library before I install it (btw: this excludes most solutions proposed in response to somewhat similar questions).
Isn't CMake supposed to work cross-platform? What is the minimally invasive adjustment to make the above build steps work under Windows?
The right way of doing this on Windows is to populate the PATH environment variable for the test run:
set_tests_properties(your_test_name
PROPERTIES
ENVIRONMENT PATH="path-containing-your-dll")
I believe you can use generator expression if path-containing-your-dll is a function of an artifact that you generate in your build.
Cherry on top: since cmake 3.13, the variable VS_DEBUGGER_ENVIRONMENT can also be set on the target for having a nice debugging behaviour inside Visual Studio (eg. being able to debug the application directly from Visual instead of going through ctest).
I recently installed vs15 - preview (Stripped down version of visual studio 2015).
I am able to compile C/C++ sources from inside the IDE, but I am not able to compile with the command line interface cl.exe. It can't find the c stdlib headers. I tried to use vcvars32.bat to set the proper reg values but seemingly it cant find the "Common Tools Folder".
"ERROR: Cannot determine the location of the VS Common Tools folder."
The script uses the env. variable "%VS150COMNTOOLS%".
If I try to run "cd %VS150COMNTOOLS%" from the cmd line, it can't find the path, so this seems to be the main problem.
How can manually set %VS150COMNTOOLS% to the right path? how can I set the cmd linker settings manually (Without telling the cl.exe every time I call it)?
Okay, I solved it by adding the path to the include directories and lib directories to the env. variables as "INCLUDE", "LIB". It works now, whyever the script was not able to set those values properly. I am not fluent in reading .bat let away writing in, I assume the directory structure, which is different for the vs15 preview when compared to the full version, had not been adapted yet.
I have 2 questions regarding NGINX:
Is there any one who had already compile NGINX with Visual Studio? I want create a VS9 Project for compiling NGINX.
It's my veritable need, is there any way to compile NGINX as Lib or DLL?
I just finished building a Visual Studio 2010 project for nginx. The process wasn't entirely straight-forward, so I will attempt to detail everything I've learned. This is a several-hour to several day process, depending on your experience.
Step 1: You must first follow the Guide for building nginx on windows. This not only builds nginx, but also creates .c and .h files that you will use when creating your Visual Studio project. It won't work without these files. (For more information, see here.)
If you are less experienced with Unix like me, the guide above leaves some unanswered questions. So I'll first flesh out that guide with tips of my own, and then later, tell you more about creating a project for Visual Studio.
Part I: Compiling nginx for windows using MSYS
First, follow all the steps given above. Install MSYS, Strawberry Perl, Mercurial, and download the PCRE, zlib, and OpenSSL libraries. Then follow these steps:
1) Open a command prompt As Administrator. Then run your Visual Studio vc\vcvarsall.bat file to set
your environment variables to use VC as the compiler. Your paths will be different, but the command I used was:
"C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"
I found that even though the Strawberry Perl added 3 paths (which you can verify by examining your PATH variable), it still was using the wrong Perl.
2) Launch MSys by running msys.bat. For me, MSys was installed inside of the MinGW directory, so my path was:
C:\MinGW\msys\1.0\msys.bat
If successful, you should see something like this in green:
JensenV#AVWMA047LB ~
(except with your username#networkaddress instead) in a window called something like MINGW32:~
You might be wondering where your 'home folder is. It's under msys\1.0\home. So on my system, it's here:
C:\MinGW\msys\1.0\home\JensenV
If you do "ls" or "dir" this is the directory you're in initially.
3) Assuming you installed Mercurial as instructed above, you should now be able to check out ngynx source:
hg clone http://hg.nginx.org/nginx
This will go into the directory mentioned above.
4) You need to make sure the version of perl being used is strawberry perl, NOT the version that comes with msys. Type:
which perl
If you get something like "/bin/perl.exe" that's the wrong perl and you need to fixing your paths. You can either mess with this (as I did, unsuccessfully) OR you can just disable the version of perl that comes with msys. I just renamed
perl.exe to perl_UNUSED.exe in my msys install:
C:\MinGW\msys\1.0\bin
Whatever you do, make sure "which perl" shows the path to Strawberry Perl before proceeding.
5) Also renamed "link.exe" in my msys\1.0\bin directory:
C:\MinGW\msys\1.0\bin
so that it's unused. (i.e. rename it to "link_UNUSED.exe")
I believe this is because, in Step 1 above, your "vcvarsall.bat" set everything to use Microsoft C's compiler/linker, but then in Step 2, the linker was changed to use the Msys one instead. You need to use the Microsoft one.
To verify renaming as "link_UNUSED.exe" was successful, type:
which link
and ensure it points to your Visual Studio 10 link, not the link.exe that came with msys.
6) First "cd nginx" then create an objs/lib folder tree inside of the nginx folder. Untar/unzip pcre, zlib, and openssl in here as mentioned in the guide.
7) While your current directory is still nginx, run nginx's autoconfigure script, but first modify the command below to change the paths for
sopenssl, pcre, and zlib to be correct for what you installed in objs/lib (your version numbers may be different). The command I used was:
auto/configure --with-cc=cl --builddir=objs --prefix= \
--conf-path=conf/nginx.conf --pid-path=logs/nginx.pid \
--http-log-path=logs/access.log --error-log-path=logs/error.log \
--sbin-path=nginx.exe --http-client-body-temp-path=temp/client_body_temp \
--http-proxy-temp-path=temp/proxy_temp \
--http-fastcgi-temp-path=temp/fastcgi_temp \
--with-cc-opt=-DFD_SETSIZE=1024 \
--with-pcre=objs/lib/pcre-8.33 \
--with-zlib=objs/lib/zlib-1.2.8 \
--with-openssl=objs/lib/openssl-1.0.1f \
--with-select_module --with-http_ssl_module --with-ipv6
If you want to change any configuration options, NOW IS THE TIME. These options affect the generated .c and .h files that you will use later in creating your Visual Studio project, and trust me, you don't want to have to redo that later when you realize you need different options.
7) Make it.
nmake -f objs/Makefile
If successful, your freshly compiled nginx.exe should be inside your home\YourUsername\nginx\objs folder. i.e. something like:
C:\MinGW\msys\1.0\home\JensenV\nginx\objs
In addition, these files will now be in the same folder as nginx.exe:
ngx_auto_config.h
ngx_auto_headers.h
ngx_modules.c
ngx_pch.c
You will use these in creating your Visual Studio project.
8) Have a beer.
**
Part II: Creating the Visual Studio nginx Project
**
Create an empty Visual Studio project for Command Line application. Save the project inside your nginx folder (root level). Note that before this step you can move your nginx folder outside of msys to wherever you want to keep it.
1) Go to Properties -> VC++ Directories and add these Include Directories:
$(MSBuildProjectDirectory)\src\core
$(MSBuildProjectDirectory)\src\event
$(MSBuildProjectDirectory)\src\event\modules
$(MSBuildProjectDirectory)\src\http
$(MSBuildProjectDirectory)\src\http\modules
$(MSBuildProjectDirectory)\src\http\modules\perl
$(MSBuildProjectDirectory)\src\mail
$(MSBuildProjectDirectory)\src\misc
$(MSBuildProjectDirectory)\src\mysql
$(MSBuildProjectDirectory)\src\os
$(MSBuildProjectDirectory)\objs
$(MSBuildProjectDirectory)\src\os\win32
$(MSBuildProjectDirectory)\objs\lib\openssl\ssl\include
$(MSBuildProjectDirectory)\objs\lib\zlib
$(MSBuildProjectDirectory)\objs\lib\pcre
NOTE: Before this step I went into objs/lib and removed the version numbers from the zlib, pcre, and ssl folders. Either you should do this to, OR you should modify the paths above to match your installed versions. I removed the version numbers so that I can update to newer versions of these libraries in the future without breaking my project.
Click on the "Macros >>" button and verify that the MSBuildProjectDirectory path is a path to your nginx folder.
2) Likewise add these paths to your Library Directories:
$(MSBuildProjectDirectory)\objs\lib\openssl\ssl\lib\
$(MSBuildProjectDirectory)\objs\lib\pcre\
$(MSBuildProjectDirectory)\objs\lib\zlib\
Again, modify these paths to include version numbers if your objs/lib folder's contents still have version numbers.
3) Change these Project Properties as follows:
C/C++
General: Set "Treat warnings as errors" to No (WX-)
Preprocessor: Add these Preprocessor Definitions:
WIN32
NGX_WIN32
NGX_MAIL_SSL
NO_SYS_TYPES_H
FD_SETSIZE=1024
Linker:
Input: Add the following to Additional Dependencies:
ws2_32.lib
pcre.lib
ssleay32.lib
libeay32.lib
crypt32.lib
zlib.lib
4) Close your Visual Studio solution. Open up the project file (ends in .vcxproj) with a good text editor, such as Notepad++. (Make a backup copy of it first, in case anything goes wrong.) Also open up nginx\objs\makefile with a text editor.
In the makefile, not too far from the top, you'll see a section that starts something like this:
objs/nginx.exe: objs/src/core/nginx.obj \
objs/src/core/ngx_log.obj \
objs/src/core/ngx_palloc.obj \
objs/src/core/ngx_array.obj \
....
objs/ngx_modules.obj \
objs/nginx.res \
objs/lib/pcre-8.33/pcre.lib \
objs/lib/zlib-1.2.8/zlib.lib
$(LINK) #<<
Likewise, in the Visual Studio file, if you've added any source code (add any files you want prior to this step, so you can see what I'm talking about) you'll see something like this:
Create a new document containing just the .obj files from the makefile. Use Search & Replace in a text editor to modify them to match the format of the Visual Studio project file instead (so ending in .c /> instead of with .obj \, and starting with
Also don't forget to change the forward slashes to backslashes. Don't include the zlib.lib or pcre.lib lines. I forget if you should include nginx.res. (Probably not.)
Once you're sure the format is right, save your Visual Studio project and try opening it. If all the files from the makefile show up in your project, you did it correctly.
5) Remember those special .c and .h files that nginx created when you built the exe? You want to add them to your project now, too. Add these guys:
ngx_modules.c
ngx_pch.c
6) Now you're ready to compile!
I've honestly probably forgotten something along the way, so you might still have some linker or compile errors to fix, but this should give you a good start!
NOTE: If you want to change which options are included in nginx, you'll have to do a new auto/configure in Part I above, a new nmake, and then include additional source code in you Visual Studio project, and use the newly generated ngx_modules.c and ngx_pch.c files in your Visual Studio project.
I am trying to compile the Qt library (I don't need the demos or examples) for 64-bit Windows. There are instructions here but I run into the error described in the comment below it. There doesn't seem to be a reference anywhere for how one might go about doing this process.
I am targetting Microsoft Visual C++ 2010 Express. It looks like I need Perl and the Windows SDK as well - how do I go about this process?
This process is quite tedious and time-consuming - but I will explain each step in detail here for the benefit of others who try to compile Qt in the future.
The first step is to install all of the prerequisites.
ActivePerl, which is used during the configuration process. You will need to restart after installing Perl since it modifies environment variables.
The Windows SDK 7.1 (formerly called the Platform SDK). Be sure to include the x64 libraries when you select the components to install.
Download the Qt source archive from the Qt Downloads page.
Extract the contents of the archive to an easy-to-remember location (like C:\). You need to remember this location later since we will be using it to set some environment variables.
Now open the Windows SDK 7.1 Command Prompt. Begin by setting the environment to 32-bit release mode (we need to build some of the tools as 32-bit applications):
setenv /release /x86
Set the following environment variables (example below assumes you extracted to C:\):
set QTDIR=C:\qt-everywhere-opensource-src-4.8.0
set PATH=%PATH%;%QTDIR%\bin
Now run cd %QTDIR% and specify the configuration options - example is included below:
configure -release -opensource -qt-zlib -qt-libpng -qt-libmng -qt-libtiff
-qt-libjpeg -qt-style-windowsxp -qt-style-windowsvista -platform
win32-msvc2010
Once the configuration process is complete, cd to the src directory and run:
qmake
nmake
This process may take a considerable amount of time, so now would be a good time to take a break and answer some questions here on Stack Overflow :)
The tools are now built and you need to compile Qt as a 64-bit library. Enter the following command:
setenv /x64
You will need to set the environment variables from step 5 again. Enter those commands now.
Run cd %QTDIR% and then rerun the configure command being sure to specify one additional option:
configure -release -opensource -qt-zlib -qt-libpng -qt-libmng -qt-libtiff
-qt-libjpeg -qt-style-windowsxp -qt-style-windowsvista -platform
win32-msvc2010 -no-qmake
The -no-qmake option is very important - it indicates that we want to skip the compilation of the qmake.exe program because we want to keep the 32-bit version.
Now things get really complicated here because of some dependency problems. The tools (like moc) that Qt needs to build the core library and some of the other components are listed as dependencies in the src.pro file. This means that the compiler will attempt to build them as 64-bit applications and then try to run them - which will of course fail on a 32-bit system. So what we need to do is edit src.pro and remove those dependencies ourselves. Scroll down near line 85 and look for a line that begins with:
!wince*:!ordered:!symbian-abld:!symbian-sbsv2 {
Each subsequent line in the section lists a sub-target and its dependencies. What you want to do now is remove all dependencies that begin with src_tools_. For example:
src_gui.depends = src_corelib src_tools_uic
Becomes:
src_gui.depends = src_corelib
There might be a better way of doing this, but I haven't figured it out yet :)
Now we cd into the src directory once again and run the following command
nmake sub-winmain sub-corelib sub-xml sub-network sub-sql sub-testlib
sub-gui sub-qt3support sub-activeqt sub-opengl sub-xmlpatterns sub-phonon
sub-multimedia sub-svg sub-script sub-declarative sub-webkit
sub-scripttools sub-plugins sub-imports
This builds only the Qt libraries and skips the tool dependencies. Note that this too may take a considerable amount of time.
You should now have 64-bit libraries in the lib folder that you can link against in your 64-bit Qt applications.
Edit: it turns out that even this wasn't enough since I still ran into some problems when linking the QtWebKit4.dll library (something about unresolved symbols). It turns out that someone else has already found the solution and you need to change QMAKE_HOST.arch to QMAKE_TARGET.arch in WebCore.pro.
Also, the above options will build QNetwork4.dll without OpenSSL support (you won't be able to access sites over HTTPS - even in a QWebView). This, thankfully isn't too hard to fix. Download and build OpenSSL for Win64 and append the options below to the command in step #9:
-openssl -I C:\OpenSSL\inc32 -L C:\OpenSSL\out32dll
(You'll have to change the paths if you installed OpenSSL somewhere other than C:\OpenSSL.)
Further edit: to save the trouble of doing this yourself, I have uploaded the compiled libraries here:
http://www.box.com/s/9710cbb278ef4890a7b5
As I mentioned in the comments to George Edison's answer, there is a bug in the Microsoft Visual C++ compiler that comes with the Windows SDK 7.1. For more information on this, see QTBUG-11445 and QTBUG-19175.
I have compiled the Qt 4.8.2 64-bit binaries following George's instructions, including the OpenSSH library. In addition, I applied Microsoft's hotfix to fix the compiler bug.
For your convenience, I have made the resulting 64-bit libraries available for download from here: https://www.box.com/s/8948c60c3cdd743ef83b
I can't find any information on how to install Qt built on Windows.
In wiki article How to set up shadow builds on Mac and Linux there's description of -prefix option in configure script but this option is not available on Windows.
I know I can use Qt right from the build folder but it does not seem the right thing not to perform an install step. One problem with this approach is size; Qt's build folder takes about 4GB space whereas after installing using binary installer Qt takes about 1GB space. I guess the difference is due to temporary files created during building. I hope some install procedure would install (copy) only needed files leaving temporary files in the build folder.
As İsmail said there's no install step for Qt on Windows.
However one can try to approximate it by performing the following operations.
Cleaning
Run make clean in the build folder to remove all temporary files.
Moving
Copy build folder to the place where you want Qt "installed". Let's call it INSTALL_DIR.
Fixing paths hardcoded in the qmake.exe executable
Run qmake -query to see what paths are compiled (hardcoded) into qmake and
a. Fix paths containing the build folder by replacing it with the INSTALL_DIR using qmake -set (1).
or
b. Create a qt.conf file in the bin subfolder of the INSTALL_DIR specifing new Qt paths inside it.
Adding current directory to include path
In Qt's provided binary distributions, the pwd is included in the QMAKE_INCDIR and thus ends up in your projects include path as ".". This does not happen by default in a custom built Qt, so you have to add the following line to mkspecs/YOUR-PLATFORM-HERE/qmake.conf file:
QMAKE_INCDIR += "."
Fixing prl files
When you add a Qt component to a project file (such as CONFIG += uitools), Qt looks in %QTDIR%/lib/QtUiTools.prl to find the library dependencies of that component. These files will have the hard coded path of the directory in which Qt was configured and built. You have to replace that build directory with the one to which you moved Qt for all lib/*.prl files.
Making source available
If you made a shadow build (build made inside folder other than the one containg sources), headers in the include subfolder only forward to the original headers. For example; BUILD_DIR\include\QtCore\qabstractanimation.h looks like this
#include "SRC_DIR/src/corelib/animation/qabstractanimation.h"
If you don't want to depend on the existence of the folder containg sources you have to copy SRC_DIR/src subfolder to your destination folder and fix all headers in the include folder so that they forward to the new location of src subfolder.
The bottom line:
The build process of Qt under Windows makes it really akward to move (install) Qt after building. You should do this only if ... well I can't find any good reason to go through all this trouble.
Remember
The easy way is to place Qt's sources in the folder where you want Qt to stay after building and make a build in this folder. This makes all steps but 1 and 4 above unnecessary.
1)
The variables you set with qmake -set are saved in the registry key
HKEY_CURRENT_USER\Software\Trolltech\QMake\<QMAKE_VERSION>.
Because of this you might have a problem when you would like to have different projects using different versions of Qt which happen to have the same version of qmake. In this case the better solution is to use qt.conf file (actually files as you need one file for each Qt installation) (option 3b).
Many of the information above come from the RelocationTricks wiki page authored by Gabe Rudy. Check out his Qt (Qt4) Opensource Windows Installers of Pre-built Binaries with MSVC 2008 project which gives you easy solution of above problems.
This answer is a replacement for steps 3 and 5 of Piotr's (currently top rated) answer above, but you may still need the other steps in his answer, depending what you're trying to achieve.
This is the operation which the official installer uses to fix the hardcoded paths during the installation: qt.520.win32_msvc2012.addons/meta/installscript.qs
This is how the operation is implemented: qtpatchoperation.cpp
This is the list of files that it fixes: files-to-patch-windows-qt5
And this shows how to invoke an installer operation as a standalone command from the commandline: Operations (Qt Installer Framework Manual)
To summarize: after moving your Qt directory to where you want it, download any one of the official Qt installers and run it with the following commandline arguments:
cd <path>
installer.exe --runoperation QtPatch windows <path> qt5
Replace <path> with the full path of your Qt directory after you moved it (the qtbase directory if you are using Qt 5). Omit the final qt5 argument if you are using Qt 4.
This will fix the hardcoded paths in qmake.exe, .prl files, and others. It gives you the exact same behaviour that the official installers have in that respect.
For the initial move, nmake "INSTALL_ROOT=\somewhere" install works for me. So that's steps 1 and 2 of Piotr's answer covered. And I haven't needed steps 4 or 6, FWIW.
I can configure QT 5 on WINDOWS (Visual Studio build) with the prefix option like:
configure -prefix C:\the\path\I\want ...
then call:
nmake
nmake install
and the latter will install Qt in C:\the\path\I\want.
I did it without problems with Qt 5.2.1 and 5.3.x, so far. So, any earlier problems seem to be fixed by now.
It's very odd people claim that there is no "make install" on Windows.
I have used it many times, and I agree that it's not what it is on other platforms, but it serves its purpose.
How I use Qt's make install on Windows (from cmd):
configure
(n/mingw32-)make
(n/mingw32-)make docs
(n/mingw32-)make install
The make install bit copies all necessary headers to be able to delete your source directory. Delete all objects and unecessary stuff:
del /S /Q *.obj lib\*.dll
rmdir /S /Q docs-build qmake tools src
This allows you to remove the source directory. I don't know what impact this has on debugging Qt source code, but it sure reduces the size of a shadow build. I use it to maintain 32 and 64 bit builds with minimal size.
Qt on Windows is not installable with make install, you will notice that Qt installer for Windows just patches dlls & pdbs for the new install location.
What I would suggest is to do a shadow build in the place you would like to install it. You can manually remove *.obj files to save up space.
Qt's own build instructions show how this is done, by search/replace within each Makefile. Assuming the source was extracted to C:\qt-4.8.3 and build was performed within that directory, then do this:
fart -c -i -r Makefile* $(INSTALL_ROOT)\qt-4.8.3 $(INSTALL_ROOT)\my-install-dir
set INSTALL_ROOT=
mingw32-make install
Then create a config file that tells qmake about its new installation path. Create a textfile C:\my-install-dir\bin\qt.conf:
[Paths]
Prefix=C:/my-install-dir
Translations = translations
Then as a final step (as Randy kindly pointed out) you need to patch qmake.exe, which can be done using a simple utility called QtMove. This same tool also automatically updates all the prl files.
Step 1: Move Qt
Cut and Paste
Current directory - C:\tools\Qt
Destination directory -C:\sim\dep\Qt
Step 2: Get Old Qt Directory
Go to C:\sim\dep\Qt\2010.02.1\Qt
Open .qmake.cache
Find variable QT_SOURCE_TREE
Note the value of QT_SOURCE_TREE
Mine was C:\tools\Qt\2010.02.1\Qt
Step 3: Patch Qt
Go to C:\sim\dep\Qt\2010.02.1\bin
The syntax is qpatch.exe list oldDir newDir
qpatch.exe files-to-patch-windows C:\tools\Qt\2010.02.1\Qt C:\sim\dep\Qt\2010.02.1\Qt
Step 4: Set Environment Variables
set QTDIR=C:\sim\dep\Qt\2010.02.1\Qt
set QMAKESPEC=C:\sim\dep\Qt\2010.02.1\Qt\mkspecs\win32-g++
set PATH=%path%;C:\sim\dep\Qt\2010.02.1\Qt\bin
set PATH=%path%;C:\sim\dep\Qt\2010.02.1\bin
You can do all of this with a batch file. This took me a fair while to work out and it has saved me a lot of time since. It's a script to automatically update a Qt installation to new locations. The batch file is available here.
There is a simple utility QtMove (http://www.runfastsoft.com) can do this easily.
Runs the relocated qmake.exe build your .pro file and everything should be linked with new Qt libs.