summaryrefslogtreecommitdiffstats
path: root/src/corelib/global/qconfig.cpp.in
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Fix qconfig.cpp embedded prefix in the CIAlexandru Croitor2021-03-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the CI on a windows we configure Qt with the following prefix -DCMAKE_INSTALL_PREFIX:PATH=\Users\qt\work\install Note the lack of the drive letter. This is intentional, so that we can abuse CMake's DESTDIR installation mechanism to install into a custom path. This causes trouble for static Qt builds in the CI. Specifically when there is no qt.conf file next to qmake, qmake -query will report a QT_INSTALL_PREFIX:/Users/qt/work/install and ultimately qmake will fail to locate the module .pri files in such a path, showing errors like: Project ERROR: Unknown module(s) in QT: core gui? If a qt.conf is placed next to qmake (even an empty one), a differenct code path is used in qmake to resolve the prefix, which returns a path with a drive letter. In a shared build, because the 'relocatable' feature is enabled by default, a different code path is used and thus the prefix is also successfully resolved. So the problem is specific to static Windows Qt builds that have no qt.conf file next to qmake. This is the exact scenario that we encounter when running static Qt tests (tst_qmake in particular). To circumvent the issue, prepend a drive letter to the prefix hardcoded into qconfig.cpp. Do that with get_filename_component(REALPATH) which apparently resolves to a fully qualified path. Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I17c885f29bfdee45bec1d6aac7c3b26723e761a3 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Remove all qmake-related data from q[make]config.cppJoerg Bornemann2021-03-111-80/+5
| | | | | | | | | | | | Now that we're not actually using qmakeconfig.cpp anymore, we can remove it together with all qmake-related information that was written into qconfig.cpp. This also moves the qtConfEntries array back to qlibraryinfo.cpp. Change-Id: I5e57d8c55613332cc3e57b11df4398d46aed259b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Read QLibraryInfo paths directly from QLibraryInfo and not from qmakeconfig.cppJoerg Bornemann2021-03-111-1/+1
| | | | | | Change-Id: I1db1c871ec6b4e572bd36df6aff7a5be8a4a706c Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Do not write Sysroot and SysrootifyPrefix into qmakeconfig.cppJoerg Bornemann2021-03-111-2/+2
| | | | | | | | Those have fixed values. Change-Id: I7f1ba8036f43413d3c805f4b419ae79e037343fb Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Remove the platformsSection constant from qconfig.cpp.inJoerg Bornemann2021-03-111-2/+0
| | | | | | | | | This is not configurable and doesn't have to be in the generated q[make]config.cpp files. Change-Id: If294d735800a3b5c6b3e269abdd86df401cf4864 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix QT_HOST_LIBEXECS for cross-builds on WindowsJoerg Bornemann2021-03-041-0/+4
| | | | | | | | | | Like for LibraryExecutables, we must default to "bin" on Windows for HostLibraryExecutables in our generated qconfig.cpp. Pick-to: 6.1 Fixes: QTBUG-91496 Change-Id: Ib5a4b3b3fd6192bd953e615058b482e67ad19462 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Simplify prefix-related functionality of qmakeAlexey Edelev2021-03-011-2/+0
| | | | | | | | | | | | | Since the QT_CONFIGURE_HOSTBINDIR_TO_HOSTPREFIX_PATH and QT_CONFIGURE_HOSTBINDIR_TO_EXTPREFIX_PATH definitions keep the same value in modern CMake build, no need to have special handling in cases where these values are used in qmake. Also it will be useful to specify the relative path to the prefix directory from the directories different of 'bin' when use QMakeLibraryInfo. Task-number: QTBUG-75870 Change-Id: I5a777001eb334dcf05e22853a514d4257352d59b Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Remove unused definitionsAlexey Edelev2021-03-011-4/+0
| | | | | | | | | | | | QT_CONFIGURE_CROSSBUILD is always '0', so it's not necessary to keep conditional compilation in QMakeLibraryInfo. Also the QT_CONFIGURE_SYSROOTIFY_PREFIX definition is never used in the project. Task-number: QTBUG-75870 Change-Id: I1fe42dce40fddc6a72254736883f93aa4727f6b3 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Use Core library for qmake instead of the Bootstrap libraryAlexey Edelev2021-02-251-0/+71
| | | | | | | | | | | | | | | | | | | Move the qmake-specific logic of the QLibraryInfo class to qmake internals. 'qconfig.cpp.in' now stores information about the library info entries to keep them consistent between qmake and the Core library. qmake requires specific features enabled in the Core library, so building qmake will be skipped if the features are not enabled. All flags directly related to the qmake have been removed from Core lib. Remove all bootstrap related sections from qmake CMakeLists.txt Task-number: QTBUG-89369 Change-Id: I26de157d3bfd4a5526699296e9d46e1c180b89ae Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* CMake: Allow specifying a sysconfdir that's outside the prefixAlexandru Croitor2020-08-131-1/+1
| | | | | | | | | Also use the value to actually write it into qconfig.cpp so that qmake reports the right information. Change-Id: Icc4bf36b0dc6ad75d93ac16f39e5b361c0ce52b4 Fixes: QTBUG-81289 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Hard-code QT_CONFIGURE_CROSSBUILD to 0Joerg Bornemann2020-07-011-0/+1
| | | | | | | | The qmake we're building is always built for the target platform. Therefore, QT_CONFIGURE_CROSSBUILD can always be set to a falsy value. Change-Id: I0f03c4ce0c75d3b4e97be5141adf742276131dcb Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Make build system of installed Qt more relocatableAlexandru Croitor2020-05-071-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Regenerate files after dev -> wip/cmake mergeAlexandru Croitor2019-10-141-1/+4
| | | | | | | | | | Note the following bigger things that had to be done: Handle GSS library / feature with a new custom find module. Implement rudimentary support for relocatability (does not currently handle extprefix). Change-Id: Ic6cd27dda7ebca9829f51cb42ea76fff6d1767ef Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Improve qconfig.cpp generationAlexandru Croitor2019-05-311-40/+4
| | | | | | | | | | | | | | | | | | We used to copy a qconfig.cpp.in file verbatim. Add some plumbing to actually compute the strings and their lengths as it is done in qtbase/configure.pri. Also make sure to replace the hardcoded linux mkspec with one that is automatically determined. Of course both the detection of the mkspec, and the hardcoded strings for include, lib, etc. should be fixed in the future. This is a stepping stone to allow building a Qt application using the qmake built by CMake. Change-Id: I2e6754f44b20b09b09d14fd85785d56288e6517b Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Begin port of qtbase to CMakeSimon Hausmann2018-11-011-0/+65
Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-08 07:16:54 +0000