CMake: Make build system of installed Qt more relocatable

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>

1 files changed, 20 insertions, 12 deletions

diff --git a/cmake/QtBuildInternalsExtra.cmake.in b/cmake/QtBuildInternalsExtra.cmake.in
index ea945a913d..7ab25082c2 100644
--- a/cmake/QtBuildInternalsExtra.cmake.in
+++ b/cmake/QtBuildInternalsExtra.cmake.in
@@ -5,18 +5,26 @@ set(QT_CMAKE_EXPORT_NAMESPACE @QT_CMAKE_EXPORT_NAMESPACE@)
 set(INSTALL_CMAKE_NAMESPACE @INSTALL_CMAKE_NAMESPACE@)
 set(QT_BUILD_INTERNALS_PATH "${CMAKE_CURRENT_LIST_DIR}")
 
-# Propagate the original install prefix, so that a developer building a child module can
-# specify CMAKE_PREFIX_PATH for finding the Qt modules instead of CMAKE_INSTALL_PREFIX.
-set(CMAKE_INSTALL_PREFIX @CMAKE_INSTALL_PREFIX@ CACHE PATH
-    "Install path prefix, prepended onto install directories." FORCE)
-
-# Save the original install prefix in an additional variable.
-# While CMAKE_INSTALL_PREFIX may be overridden in certain cases (like for standalone tests building
-# or for singular qt-cmake-standalone-test usage), we still need the original qtbase install prefix
-# to know where the shared libraries are located to inject them into PATH when running tests via
-# ctest.
-set(QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX @CMAKE_INSTALL_PREFIX@ CACHE PATH
-    "Original install prefix specified when building qtbase." FORCE)
+# The relocatable install prefix is meant to be used to find things like host binaries (syncqt),
+# when the CMAKE_INSTALL_PREFIX is overridden to point to a different path (like when building a
+# a Qt repo using Conan, which will set a random install prefix instead of installing into the
+# original Qt install prefix).
+get_filename_component(QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX
+                       ${CMAKE_CURRENT_LIST_DIR}/../@qt_path_from_cmake_config_dir_to_prefix@
+                       ABSOLUTE)
+
+# If no explicit CMAKE_INSTALL_PREFIX is provided, force set the original Qt installation prefix,
+# so that further modules / repositories are  installed into same original location.
+# This means by default when configuring qtsvg / qtdeclarative, they will be installed the regular
+# Qt installation prefix.
+# If an explicit installation prefix is specified,  honor it.
+# This is an attempt to support Conan, aka handle installation of modules into a
+# different installation prefix than the original one. Also allow to opt out via a special variable.
+if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT AND
+   NOT QT_BUILD_INTERNALS_NO_FORCE_SET_INSTALL_PREFIX)
+    set(CMAKE_INSTALL_PREFIX @CMAKE_INSTALL_PREFIX@ CACHE PATH
+        "Install path prefix, prepended onto install directories." FORCE)
+endif()
 
 # Propagate developer builds to other modules via BuildInternals package.
 if(@FEATURE_developer_build@)