Getting qmake to work with a 32bit and 64bit side by side installation

Question

I want to have the Qt version we are building against under source control and would like to have a side by side build of both 32 and 64 bit Qt from the same source folder in order to save space in source control.

Setting up the library paths is easy, I just have QMAKE_LIBDIR_QT=$$PWD/Shared/Qt/$${QT_MAJOR_VERSION}.$${QT_MINOR_VERSION}.$${QT_PATCH_VERSION}/lib/$${ARCH} in my qmake file and a similar declaration for QMAKE_LIBDIR.

However dividing the bin/ folder is less easy. When using qmake from a .../bin/x64 folder it detects QT_HOST_BIN and QT_INSTALL_BINS as .../bin/ and when I build it tries to run uic and other tools from this folder and fails.

The documentation states that these variables can be set by running qmake -set QT_HOST_BIN path but this appears to be a system wide setting, which is undesirable and doesn't work anyway, neither does setting them as environment variables.

At this point I am inclined to give up and go for two separate Qt installations for 32 and 64 bit. Especially since I haven't even started to look at how to deal with the plugins folder yet. It seems as if Qt just doesn't even begin to consider a multi-arch build setup.

Answer 1

There's no need for any of this complexity. You need 3 or 5 folders:

1. The Qt source folder, within your working copy.
2. The 32 bit build folder.
3. The 64 bit build folder.
4. The 32 bit install folder.
5. The 64 bit install folder.

If you wish to store the binaries in the source control, you only need to store folders 4 and 5 in addition to folder 1.

There's no tweaking of any files within Qt's sources. When building your project that uses Qt, you must use the qmake from either folder #2 or folder #3, depending on your choice of the build. You can also build for multiple Qt versions that way, including building for Qt 4 and Qt 5.

Since it's sheer insanity to have to keep binaries in your source control, you should write a toplevel makefile or batch file that:

• Configures, builds and install each Qt build that you need.
• Runs relevant qmakes to prepare the makefiles for your project.
• Finally, builds the project.

Then, upon a checkout, all you need to get everything built is running just one script or make. You should also bundle jom.exe from a download of Qt Creator, as that will parallelize the building of nmake makefiles.

I stress that there are no changes needed to any of the Qt sources, and you don't need to do anything in your project files to use a particular version of Qt. Everything is determined by the qmake you invoke to set up the Makefiles for the project.

You need to use shadow build folders for your application, too. Generally speaking, it's counterproductive not to use shadow build folders. They can save a lot of time when rebuilding for multiple targets after small source changes. Never mind the need to keep multiple copies of source folders in sync when not using shadow builds. It's just not worth it.

Answer 2

I found this answer which points towards qt.conf. I figured out that having different qt.conf files in the bin/x64 and bin/x86 folders I can point them at different folders, for example:

[Paths]
Prefix = ../..
Binaries = bin/x64
Plugins = plugins/x64

Using this setup the build works successfully with separated bin/ folders.

However another problem I discovered while reading that answer is that all of the .prl files will have hardcoded paths in them. Which means that this will probably not build if the code is ever checked out to a different directory. I will have to ask about this in another question to see if putting Qt under source control is even possible.

Edit: For now it seems as though it is possible to get around this by editing all of the .prl files to use relative paths. I'm not sure why they weren't relative paths to begin with since it seems like you are not expected to mess with the directory structure.