This provides better stack traces and easier debugging in CI VMs.
Put the MSVC check for disabling stripping into the same place so
there's one location to decide whether stripping should happen.
Amends 60d804c567
Pick-to: 6.6
Fixes: QTBUG-118070
Change-Id: I4684036c8a5a137d14eea58954b34fe1ceb7f804
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Introduce the qt-cmake-create script. The script generates the simple
CMakeLists.txt based on the source files located in the current or
specified directory. The initial version can generate a CMake code for
the following file types:
- .c .cc .cpp .cxx .h .hh .hxx .hpp - generates the qt_add_executable
call with prerequisites.
- .qml .js .mjs - generates the qt_add_qml_module call with
prerequisites.
- .ui - adds the found ui files to the existing executable. Requires
C++ files be present in the directory too.
- .qrc - generates the qt_add_resources call and adds the resources
to the existing executable. Requires C++ files be present in the
directory too.
- .proto - generates qt_add_protobuf call with prerequisites.
The QtInitProject.cmake script contains the 'handle_type' function that
allows extending the script capabilities and establish simple relation
chains between the file types.
Note: The initial implementation doesn't deal with sub-directories, so
all files from sub-directories will be added to and handled in the
top-level CMakeLists.txt file. This can be extended by user request.
Task-number: QTBUG-104388
Change-Id: I5abd9e07da109e867ff95986572ed2bf02ef9d3d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Patching inconsistent path separator in Batch file. This at some point
may lead to something similar to the mentioned task.
Pick-to: 6.4 6.5
Task-number: QTBUG-109857
Change-Id: I36c05dc7a0b7daf3dc5dced61f3c3f7d90eb59e3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
We agreed that qt-configure-module needs to come back to bin/ as it's
user-facing.
Amends d77ce33082
[ChangeLog][CMake] Upon further consideration, qt-configure-module
was deemed user-facing, and was thus moved back to ./bin on
all platforms.
Task-number: QTBUG-107621
Change-Id: I1f7874436e5b3988242091fc0303ea828f29d5c6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In cross builds, we are not creating versioned links for qt tools. This
patch addresses that. I've changed the signature of the
`qt_internal_install_versioned_link` such that it can be used for
non-target as well, so in cross build the qmake or qtmake.bat can be
processed with the same function.
Fixes: QTBUG-109024
Change-Id: I246621c18325d084622ca92b422e815ed06f1381
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Put quotes around args var and add e and u flags, which
do the following:
e - terminates the script if an error occurs. This is
certainly desirable behavior. We don't want the script to chug
along with unpredictable behavior if an error occurred.
u - terminates the script if an undefined variable is encountered.
It is also desirable to terminate here because it might lead to
unexpected behavior.
Change-Id: Ia02196ef3eab64521e36771530d033a15bb40ecc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
When calling qt-cmake on the command line, we don't usually force
usage of a particular CMake generator and defer to the user's choice
or CMake's default for the host OS.
In the case of iOS, the generator that makes the most sense to use is
Xcode. One could also use Ninja / Unix Makefiles if the project
is only building static libraries, but for shared libraries and
executables the project likely needs the code signing
provided by xcodebuild.
When targeting iOS, use a different qt-cmake file template.
The iOS-specific shell script will set the CMAKE_GENERATOR environment
variable to 'Xcode'.
If no -G or -D CMAKE_GENERATOR is provided on the command line then
the project will use the Xcode generator. Otherwise the generator
given on the command line takes precedence.
The CMAKE_GENERATOR environment variable from the parent process is
completely ignored.
The logic is only done for iOS, to reduce the likeliness
of breaking the qt-cmake script for other platforms.
Note that Qt Creator does not use qt-cmake, but rather calls cmake
directly with additional options like the toolchain file,
architecture, sysroot, etc.
[ChangeLog][iOS][CMake] qt-cmake now defaults to using the Xcode
generator when targeting iOS projects.
Pick-to: 6.2 6.3
Fixes: QTBUG-100834
Change-Id: I39b3dce47cc9ee2f98678631e4bd035c59c65294
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
The qtpaths tool is supposed to replace "qmake -query", and it must be
available for cross-builds as a wrapper script like qmake.
Re-use the existing facility for creating the qmake wrapper script for
creating the qtpaths wrapper script.
Pick-to: 6.2
Fixes: QTBUG-97821
Change-Id: I460bae61a531994422e1c0fba09c79e4aa65713f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Now it's possible to display a configure help screen per module with
qt-configure-module <module-source-dir> -help
Pick-to: 6.2
Fixes: QTBUG-95943
Change-Id: I7d26006246af4b38b5a2ec6deca3f45c5313afec
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is a preparation for adding the -help argument to
qt-configure-module.bat.
Consider the call
qt-configure-module.bat path/to/qt-module -help
Internally, we called
cmake ... -P .../QtWriteArgsFile.cmake path/to/qt-module -help
which was supposed to separate the arguments and write them into
config.opt.
However, passing arbitrary arguments after "-P script.cmake" only worked
by accident and is not supported. As soon as arguments are passed that
are valid CMake arguments, like -help or -G, the CMake call would fail.
Now, we let configure.bat and qt-configure-module.bat write the
arguments as is into config.opt.in and let QtWriteArgsFile.cmake read
this file, separate the arguments and write config.opt.
Pick-to: 6.2
Task-number: QTBUG-95943
Change-Id: I80f298a2aaf55b0f79fed86320a055eb2d2b6faa
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Currently in order to compile a Qt6 test standalone one needs to use
the qt-cmake-standalone-test script which will load the
Qt6BuildInternals/QtStandaloneTestTemplateProject/CMakeLists.txt project
with the current test source directory to create a complete CMake project.
This commit will allow a test to have these lines at top:
cmake_minimum_required(VERSION 3.16)
if (NOT QT_BUILD_STANDALONE_TESTS AND NOT QT_BUILDING_QT)
project(a_qt_test LANGUAGES C CXX ASM)
find_package(Qt6BuildInternals COMPONENTS STANDALONE_TEST)
endif()
and be standalone and work with any IDE capable of loading CMake projects.
Fixes: QTCREATORBUG-25389
Pick-to: 6.1
Change-Id: If3f878b7e560a8bfbb604a8f1aa30b7962742e66
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The original issue #20713 is fixed, but there's still #21475 to be fixed
before we can remove qt-cmake-private-install-cmake.
Extend the comment to mention this.
Change-Id: I7a2d794ae23e2b8bc7bd27527cbc8a32b1e78e1b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
To not disturb the qmake build we kept syncqt.pl in <src>/bin but
installed it to libexec. This is not necessary anymore.
This also removes the need for having syncqt.pl in both, bin and libexec
in the build dir of qtbase.
Pick-to: 6.1
Fixes: QTBUG-91076
Change-Id: I44b014ea41e3f00c420e02fd5c76f11169340b8c
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
This script was aiding users to port from Qt 4 to 5 and is considered
to be of little value for Qt 6.
Pick-to: 6.1
Change-Id: I26fb97d32969463d94e38222e32f241f86ad9193
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The source permissions are transferred when using configure_file for
non-prefix builds. This allows running qt-cmake-standalone-test in
both non-prefix and prefix builds.
Change-Id: I38829901d0bd4dfc4b89c665169798052b218fb0
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Despite being installed in the the binary directory, this
CMake snippet cannot be executed.
Pick-to: 6.0
Change-Id: Ibfd31e51184f0688d19ac063804cc200c95555a7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Make paths in qt-cmake-standalone-test relative to script's PWD.
Fixes: QTBUG-88380
Change-Id: I6ab507c31ebed391f4e85bc6fe3f7f747dd97d54
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Passing arguments with equal signs was broken for configure.bat and
qt-configure-module.bat. An argument FOO=BAR was split at = and written
as
FOO
BAR
to config.opt, breaking every attempt of assigning CMake variables.
We must not iterate over %* in batch files to avoid splitting arguments
at equal signs. Instead, pass %* unmodified to a CMake script that
writes config.opt.
Fixes: QTBUG-88019
Change-Id: I7c743a206961d1ed168f2313f864905f6b345b49
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In a subsequent change we will call another CMake script from
qt-configure-module.bat. Write the location of qtbase/cmake into the
generated scripts instead of the path to QtProcessConfigureArgs.cmake.
Change-Id: Ie333b16d310b215c6e49efa27740c7525453d28f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMake's --install --strip command will result in calling ${CMAKE_STRIP}
after installation.
On the build machines we have multiple compilers, and ${CMAKE_STRIP} will
have a valid program e.g. C:/strawberry/c/bin/strip.exe
This will change the MSVC binaries to have a MinGW linker version flag,
which confuses Qt Creator when setting up a MSVC Kit.
Amends 2044992eed
Fixes: QTBUG-87735
Change-Id: I1b3d4cc122b3f502810d48e0443f39824016cab5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is meant to be called by our CI instructions to build standalone
tests of a Qt repository.
Currently it just calls qt-cmake with
-DQT_BUILD_STANDALONE_TESTS=ON, but it might contain more things in
the future.
The script also simplifies configuring standalone tests locally, due
to not having to remember the name of the magical variable.
Change our CI instructions to use the new script.
Change-Id: I6bc02b4e94adc9d0d05fecb0fe70a561043271f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
For QMake's -install argument it's necessary to have -qtconf in front.
Task-number: QTBUG-87801
Change-Id: I042acdd143972cc4065660035b02678db891157f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We're ensuring its existence right in the next line.
Change-Id: If7a55511c9ef839a9f9ae70a7928b58ad768ae65
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We need to make sure to create a config.opt file, even if it's empty.
This is the same fix we did for the .bat file in
dad9550305.
Change-Id: I79c507cfe0f9517d3033a773d3a5cf69eb13cfe6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Declaring and implementing out of line a specialization for
QESDP's destructor is needed if we have an implicitly shared
type and we want to provide an inline move constructor for it.
The code is however a bit heavy on the eyes, and the full
implementation for the destructor must be provided (read:
copy and pasted) -- the specialization destructor cannot
just "reuse" the one from the primary template.
This patch adds a few macros to streamline the above, so
that we can start using the same pattern in more places.
These macros are completely private for the moment being;
we don't want to push this solution for our users.
Port QPixmap to the new macros.
Change-Id: Ia6a51ad988483e44c9d97c0eca2fb003b6bd21e3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
To avoid big artifact sizes, strip the binaries and libraries upon
installation. This achieves stripping similar to QTBUG-69767 and
QTBUG-81301 but arguably in a cleaner CMake way.
See comment on PS34 of the unmerged commit
90b09fee44b08b65a436fd15fda2526e242f7b21 for details.
Task-number: QTBUG-86053
Change-Id: I3ed929a8a7c74b88c480543212fc9551d8bde77f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We need to make sure to create a config.opt file, even if it's empty.
Change-Id: If1e41cea2f3b5f3ce67f30285b77c58f7376546a
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Add a convenience script to configure a Qt module separately.
This script reads and interprets the qt_cmdline.cmake files of the
Qt module to be configured and eventually calls qt-cmake-private.
Example usage:
<install-prefix>/bin/qt-configure-module <source-root>/qtdeclarative
-qml-network -- --trace-expand --trace-redirect=cmake.trace
Change-Id: I026f1a050cd3f4df740611c32ba8c03161bba7a3
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Normalize newlines so that headers on Windows are not
always treated as outdated.
This amends 108fb2f197.
Task-number: QTBUG-86121
Change-Id: I46ddb3c5b42852bff75fd56ca224c555ac0bae94
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This makes sure the executable is run as a shell script
with the proper interpreter on Unix systems.
Otherwise it will fail in some shells, like fish.
On windows, it prevents all commands in the batch file
from displaying on the screen.
Change-Id: If554262f172b035b9661b3e2ff26a96789fa707b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously syncqt did not write content to forwarding headers if they
already existed in the target location, regardless of the contents of
the forwarding header.
This is different from syncqt's behavior when it actually copies
the headers to the target location, instead of creating a forwarding
header that includes another header.
Fix syncqt to read existing forwarding header content, and update the
content in case if it's different from the newly generated content.
This should fix the following non-prefix build case: running syncqt
from a different source + build directory would not update the
forwarding headers in the qtbase build dir.
Change-Id: Ia0a1665a36ce54f1c487101d9a7532fc0aa40c89
Reviewed-by: Brett Stottlemyer <bstottle@ford.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When cross-compiling, we now create a target_qt.conf file that's to be
used with the host Qt's qmake. With "qmake -qtconf .../target_qt.conf"
projects can be cross-built against the cross-built Qt.
We also create wrapper scripts for the host qmake to save the user from
passing the -qtconf argument.
Fixes: QTBUG-82581
Change-Id: Ib5866e7e820369efea9eb3171e3e3e3ca5c0c3c1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Calling cmake --install . only installs a single configuration.
To install both debug and release artifacts, the install
invocation needs to be done for each configuration.
To keep the Coin instruction code simpler, delegate the looping
over configurations to a custom CMake script, and use it in the
Coin instructions.
Replace all cmake --install calls in the instructions with calls
to either call_host_install.yaml or call_target_install.yaml.
The path to the script depends on whether we are building
qtbase or another module. In the former case the script should
be called from the build dir, otherwise from the install dir.
The other distinction is whether the host or target env prefix
needs to be added.
Task-number: QTBUG-80900
Change-Id: Ied4bf739e2b1a2307f22fc79c1cfad746c8cbc44
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Aka handle CMAKE_INSTALL_PREFIX in a more relocatable way.
The following story inspired this change.
If a user wants to build a Qt repo into a different install prefix
than the usual Qt one, this will fail configuration because we
look for various things like syncqt, qdoc, etc relative to
CMAKE_INSTALL_PREFIX, which will now point to a different location
where none of the above tools are located.
The intent for such a use case is to support building Qt packages with
Conan, which sets a random install prefix when configuring a repo.
The idea is to derive the qt prefix dynamically from the
QtBuildInternals package location. Essentially it's a reverse relative
path from the QtBuildInternalsConfig.cmake file to the install prefix
that was specified when initially configuring qtbase.
Once the dynamic prefix is computed (so we know where the possibly
relocated Qt is), we can find tools like syncqt and qdoc.
This is an initial attempt to support a use case like that.
More design work will probably needed in case if tools / libs need to
be found in a location different than the Qt install prefix (so
support for multiple install prefixes / search paths).
An example of such a case would be when building qtdeclarative and
qtquickcontrols2 as Conan packages in one go. Most likely the
qmltyperegistrar tool will be located in the random install prefix
set by Conan, so building qtquickcontrols2 might fail due to not
finding the tool in the original Qt install prefix.
As to the implementation details, the change does the following:
- Dynamically computes and sets the
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable when
find_package()'ing QtBuildInternals. It's an absolute path
pointing to where the relocated Qt is.
- When building qtbase this variable is not yet available (due
to QtBuildInternalsExtra not existing), in that case we set
the variable to the absolute path of CMAKE_INSTALL_PREFIX
(but only for the initial qtbase configuration).
- Remove QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX which was used
for standalone tests purposes. It's not needed now that we compute
the location of the Qt prefix dynamically.
- The Unixy qt-cmake and qt-cmake-private shell scripts now
use a relative path to find the toolchain file we created.
- The toolchain file also dynamically computes the location of the Qt
packages, and adds them to CMAKE_PREFIX_PATH.
- A lot of existing CMAKE_INSTALL_PREFIX uses are replaced with
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX. This includes finding
tool locations, mkspecs dir, path environment setup for tools, etc.
- Some places still use CMAKE_PREFIX_PATH in the following cases
- When determining paths while configuring qtbase (valid cases)
- When I wasn't sure what the behavior should be, so I left them
as-is (an example is documentation generation, do we want to
install it into the random Conan prefix, or into the main prefix?
Currently it installs in the random prefix).
Note that relocating a Qt installation does not work for non-prefix /
non-installed builds, due to hardcoded paths to include directories
and libraries in generated FooTargets.cmake files.
Task-number: QTBUG-83999
Change-Id: I87d6558729db93121b1715771034b03ce3295923
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Otherwise we will fail to resolve the symbol and will not create
a forwarding header for the class.
Change-Id: I34922d8458bdb994a194108183ac9b9d14530c5e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Before this patch there were a few ways to build tests
- Configure all tests as part of the repo build
- Configure all tests as part of the repo build, but don't build
tests by default (-DQT_NO_MAKE_TESTS=ON)
- Configure all tests as a standalone project in a separate build
dir using -QT_BUILD_STANDALONE_TESTS=ON
All of the above incur some time overhead due to the necessity
of configuring all tests.
Sometimes you just want to build ONE test (or a few).
To facilitate that use case, a new shell script called
bin/qt-cmake-standalone-test(.bat) can now be used to configure
and build one or more tests.
The script takes one single argument pointing to the desired test
project path and configures a generic template project that sets up
all the necessary Qt CMake private API, afterwards calling
add_subdirectory on the passed in project.
Example
$ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image/qicon
or
$ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image
After that, simply run 'ninja && ctest' to build and run the test(s).
This is the CMake equivalent of calling qmake on a test .pro file
(or on a tests SUBDIRS .pro file)
There are 3 details worth mentioning.
Due to the add_subdirectory call, the built artifacts will not
be in the top-level build dir, but rather in a nested build_dir.
The script currently can't handle more than one argument
(the path to the project), so you can't pass additional
-DFoo=bar arguments.
If a test uses a 3rd party library (like Threads::Threads)
which was not a public dependency for any of the Qt modules,
configuration will fail saying that the target was not found.
Perhaps we should consider recording these packages when
generating the StandaloneConfig.cmake files.
Change-Id: Icde6ecb839341d34f341d9a19402c91196ed5aa0
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This allows doing debug_and_release builds with Ninja on all
platforms.
The "Ninja Multi-Config generator" is available starting with CMake
3.17.
Desired configurations can be set via CMAKE_CONFIGURATION_TYPES.
Possible values: "Release, Debug, RelWithDebInfo, MinRelSize".
For example -DCMAKE_CONFIGURATION_TYPES="Release;Debug".
The first configuration is the 'default' configuration which is
built when calling ninja with no arguments.
To build all targets of a certain configuration use "ninja all:Release"
or "ninja all:Debug".
To build all targets in all configurations use "ninja all:all".
Note that the first configuration influences which configuration of
tools will be used when building the libraries for all configurations.
In simple terms, when configured with
-DCMAKE_CONFIGURATION_TYPES="Release;Debug" the release version of moc
is used by AUTOMOC.
When configured with -DCMAKE_CONFIGURATION_TYPES="Debug;Release"
the debug version of moc is used by AUTOMOC.
Framework builds and Ninja Multi-Config don't currently work together
due to multiple bugs in CMake, which ends up generating an invalid ninja
file with duplicate rules. There are also issues with placement of the
debug artifacts.
This will be handled in a follow up patch after CMake is fixed.
Task-number: QTBUG-76899
Change-Id: If224adc0b71b7d1d6606738101536146aa866cd7
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Rather than tweaking the parser to cover every eventuality with corner
case lines that could cause incorrect header files to be created then
the means to suspend/resume the processing of a file is added.
This enables us to have it skip over the template line that is causing
a QList header to be created as part of the QtGui headers. This patch
includes the fix to solve this in addition.
Fixes: QTBUG-68129
Change-Id: I751646c4b20a4434347c149ae5e6dcb6e7618853
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This broke when QLatin1Literal got deprecated in change 45373c1924
Both hunks in this patch are needed. The hunk in syncqt.pl removes the
QT_DEPRECATED_X(...) macro if it appears solely on a line in source code,
the second hunk inserts a newline after the QT_DEPRECATED_X(...) macro usage
to trigger that code path in the Perl script.
Before/after comparison of the headers generated in include/QtCore:
```
% diff ~/old.txt ~/new.txt
105a106
> QLatin1Literal
```
Change-Id: I468dd2dd54bf115521ed82c6182236905556f568
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
In Windows-msys syncqt.pl expects CRLF line endings, and does not
work correctly with LF. syncqt.pl was fixed to be line-ending-agnostic.
Task-number: QTBUG-77192
Change-Id: Ie8029238bdd580bcf042ede0d0f64d5f01488406
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Modified a regular expression in syncqt.pl so that the special case of
a class beginning with another class does not lead to the exclusion of
the first one. This affects the generation of the install target for
generated class headers of Qt modules. Now the expression verifies the
class names are not identical.
Fixes: QTBUG-71323
Change-Id: I210b4d4c3ed64cf189594b95b10aa0e8495a19d2
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Previously the cmake install prefix was added twice during a non-prefix
build, which evaluated to an incorrect path.
Set another absolute dir variable, and use that instead.
Change-Id: I73099510dadc8f401d5a763f21840c9671686c10
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
