Details
Description
On Windows, the @ApplicationsDir@ predefined variable uses the value from CSIDL_PROGRAM_FILES (libs/installer/packagemanagercoredata.cpp).
On a 64-bit Windows PC, if a 32-bit build of the installer is used, this returns the "Program Files (x86)" directory. If a 64-bit build of the installer is used, the "Program Files" directory is returned.
This makes the installer a little inconsistent; it is the product that is being installed that is built for a particular architecture.
One could mandate that the specific build of the installer should be used, depending on the target architecture, but it would nice if this was not the case. Also, it's convenient to use the pre-built binaries, and, as far as I can tell, the 64-bit Windows version is not pre-built.
A script can be used to workaround this condition, but an alternative predefined variable would be convenient; e.g. @ApplicationsDir3264@, which is based on the target's architecture, not the installer's. I.e would always return "Program Files".
However, this does open a can of worms, because one might specifically require the 32-bit "Program Files (x86)" or the 64-bit "Program Files" (@ApplicationsDir32@ and @ApplicationsDir64@ ).
Attachments
Issue Links
- replaces
-
QTIFW-525 Applications directory can not be properly derived if 32-bit binarycreator.exe is used to create an installer for a 64-bit application
- Closed