summaryrefslogtreecommitdiffstats
path: root/src/corelib/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* Extend QSequentialIterable and add QAssociativeIterableUlf Hermann2020-09-191-1/+3
| | | | | | | | | And add mutable iterators. This requires some refactoring of the existing iterators. Task-number: QTBUG-81716 Change-Id: I61b3a3e8c0df5fd449679257a29d9f0c3d19c4f0 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* CMake: Fix race condition in -trace configured buildJoerg Bornemann2020-09-101-0/+5
| | | | | | | | | | | | qt_create_tracepoints(Core) creates a dependency from Core to Core_tracepoints_header, but the helper library Core_qobject also uses qtcore_tracepoints_p.h and must therefore depend on Core_tracepoints_header too. This amends 5c092c2b401. Change-Id: I0ed51f3ab9accea00f524c170cd319bb8af11df7 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Remove some pre-Qt6 codeEdward Welbourne2020-09-101-1/+0
| | | | | | Task-number: QTBUG-85700 Change-Id: Id4856d035b697276f6a7090956359044bac7d817 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
* Get rid of the MSVC specific fileLars Knoll2020-09-051-7/+0
| | | | | | | | | It used to contain the MSVC specific export hack for QVector, but that one is not required in Qt 6 anymore and the file was not doing anything anymore. Change-Id: Ic8b4aa355a8934beb6abcf10235d218344a294cc Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Reimplement QSequentialIterable using QMetaSequenceUlf Hermann2020-09-031-0/+1
| | | | | Change-Id: Ie721a5f0caa697c4bf15a81f3762cf79d3c54f5a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Fix static buildFabian Kosmale2020-09-021-1/+1
| | | | | Change-Id: I52a31c76d2acb996ae5cf0b2ee6d221864d76b28 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Add a QMetaSequence interfaceUlf Hermann2020-09-011-0/+2
| | | | | | | | | | | | | | | This is in line with QMetaType and will be used to implement a mutable QSequentialIterable. Later on, a QMetaAssociation will be added as well, to implement a mutable QAssociativeIterable. The code here represents the minimal set of functionality needed to have a practical sequential container. The functionality is not completely orthogonal. In particular, the index based operations could be implemented in terms of iterator-based operations. Task-number: QTBUG-81716 Change-Id: Ibd41eb7db248a774673c701549d9a03cbf2e48b6 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Long live Q{Any,Utf8}StringView!Marc Mutz2020-08-311-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to add these two classes at the same time, because QAnyStringView makes all QUtf8StringView relational operators moot. We might want to add some later, esp. for UTF-8/UTf-8 comparisons, to avoid the pessimization that we can't early-out on size() mismatch in QAnyStringView equality operators, but that's an optimization, not a correctness issue, and can be fixed in a source-compatible way even after Qt 6 is released. To deal with the char8_t problem in C++20, make QUtf8StringView a class template out of which two UTF-8 views can be instantiated: the Qt 7 version, which depends on C++20 char8_t as value_type, and the Qt 6 version where value_type is a char. Use inline namespaces to map the QUtf8StringView identifier to one or the other, depending on the C++ version used to compile the user code. The inline namespace names must needs be a bit ugly, as their inline'ness depends on __cpp_char8_t. If we simply used q_v1/q_v2 we'd be blocking these names for Qt inline namespaces forever, because it's likely that inline'ness of other users of inline namespaces in Qt depends on things other than __cpp_char8_t. While inline'ness of namespaces is, theoretically speaking, a compile-time-only property, at least Clang warns about mixed use of inline on a given namespace, so we need to bite the bullet here. This is also the reason for the QT_BEGIN_..._NAMESPACE macros: GCC is ok with the first declaration making a namespace inline, while Clang warns upon re-opening an inline namespace as a non-inline one. [ChangeLog][QtCore][QUtf8StringView] New class. [ChangeLog][QtCore][QAnyStringView] New class. Change-Id: Ia7179760fca0e0b67d52f5accb0a62e389b17913 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Remove MSVC workaround for QPolygonMarcel Krems2020-08-291-1/+1
| | | | | Change-Id: I62f7c6da7629dcdfda653a136d3bcd483359c86c Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Move QStateMachine from QtCore to QtScxmlKarsten Heimrich2020-08-241-13/+0
| | | | | | Task-number: QTBUG-80316 Change-Id: I2ee74110fd55e94d86321d3b3dc5bb8297424ed4 Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
* Get rid of the unused meta type switcherLars Knoll2020-08-241-1/+0
| | | | | Change-Id: I8771feb68227bf69643b66314284c645cccdec6f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Refactor qxmlstream_p.hLars Knoll2020-08-191-0/+2
| | | | | | | | | | Pull the file apart, so that the parts generated from qxmlstream.g are separated from the definition of the private class. This will in the future simplify maintenance and refactoring. Change-Id: I4a9c1bb1e377dee1e6d3b9aa9b0dfa64c5806c45 Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
* Remove binary compat sources for qbytearray and qstringAllan Sandfeld Jensen2020-08-191-3/+0
| | | | | | | No longer needed in Qt6. Change-Id: I29567e175e07cc3658f0619acfd604abf64f6459 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* CMake: Fix what Android plugin suffix should be passed as a defineAlexandru Croitor2020-08-171-1/+1
| | | | | | | | | | | | | | | | CMAKE_SYSTEM_PROCESSOR has the value i686 when targeting the x86 Android ABI, which is set by the Android CMake toolchain. This is not the value that Qt expects, and potentially breaks loading of Qt plugins. The same with aarch64 instead of arm64-v8a. In qmake the proper values for QT_ARCH variable are the equivalent of the ANDROID_ABI variable set by the CMake toolchain file, so use ANDROID_ABI. Task-number: QTBUG-85399 Change-Id: Ia2eaceb75168cddb2d28414f1f4bf481ec76f29e Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Disentangle QIODevice dependenciesLars Knoll2020-08-151-0/+1
| | | | | | | | | | | | | | | | | Move the QIODevice::OpenMode enum into a base class, so that we can remove the full QIODevice (and thus QObject) dependency from qdatastream.h and qtextstream.h. This is required so that we can include QDataStream in qmetatype.h without getting circular dependencies. As a nice side effect, QDataStream and QTextStream can now inherit QIODeviceBase and provide the OpenMode enum directly in their class scope. Change-Id: Ifa68b7b1d8d95687ed032f6c9206f92e63bfacdf Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
* CMake: Split out some Android functions into a public API fileAlexandru Croitor2020-08-141-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To fix CMake Qt For Android projects to configure, we need to move some functions from a private CMake API file only, to a public one. Add Qt6AndroidMacros.cmake which will be loaded by Qt6Core package. We'll have to decide how we proceed with Qt5AndroidSupport.cmake, because that file automatically runs code when included in Qt5, and we usually don't want to do it. We'll also have to decide how to handle the define_property() calls that are still left in the private QtPlatformAndroid.cmake file. With this fix, Qt example CMake projects that use add_qt_gui_executable should now be buildable. An APK can be created with 'ninja apk'. Unfortunately Qt Creator 4.13 does not currently seem to support opening and building CMake Qt For Android projects properly. While the build succeeds after fiddling with the Kit settings, the APK deploy step fails to run (at least on my machine). So the simplest way to run the built APK is to open the android-build dir with Android Studio and launch the example application from there. Task-number: QTBUG-85399 Change-Id: I77f246331de7a6e9e6d4ba7d973730190138f136 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Properly handle CONFIG += thread aka Threads::ThreadsAlexandru Croitor2020-08-061-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mkspecs/features/qt.prf adds a dependency on the system threading library if the Qt Core thread feature is enabled. Because qt.prf is loaded by any public or internal Qt project, it's essentially a public dependency for any Qt consumer. To mimic that in CMake, we check if the thread feature is enabled, and and set the Threads::Threads library as a dependency of Qt6::Platform, which is a public target used by all Qt modules and plugins and Qt consumers. We also need to create a Qt6Dependencies.cmake file so we find_package(Threads) every time find_package(Qt6) is called. For the .prl files to be usable, we have to filter out some CMake implementation specific directory separator tokens 'CMAKE_DIRECTORY_ID_SEP' aka '::@', which are added because we call target_link_libraries() with a target created in a different scope (I think). As a result of this change, we shouldn't have to hardcode Threads::Threads in other projects, because it's now a global public dependency. Task-number: QTBUG-85801 Task-number: QTBUG-85877 Change-Id: Ib5d662c43b28e63f7da49d3bd77d0ad751220b31 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Long Live QMap as a refcounted std::map!Giuseppe D'Angelo2020-08-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... and QMultiMap as std::multimap. Just use the implementation from the STL; we can't really claim that our code is much better than STL's, or does things any differently (de facto they're both red-black trees). Decouple QMultiMap from QMap, by making it NOT inherit from QMap any longer. This completes the deprecation started in 5.15: QMap now does not store duplicated keys any more. Something to establish is where to put the QExplictlySharedDataPointer replcement that is in there as an ad-hoc solution. There's a number of patches in-flight by Marc that try to introduce the same (or very similar) functionality. Miscellanea changes to the Q(Multi)Map code itself: * consistently use size_type instead of int; * pass iterators by value; * drop QT_STRICT_ITERATORS; * iterators implictly convert to const_iterators, and APIs take const_iterators; * iterators are just bidirectional and not random access; * added noexcept where it makes sense; * "inline" dropped (churn); * qMapLessThanKey dropped (undocumented, 0 hits in Qt, 1 hit in KDE); * operator== on Q(Multi)Map requires operator== on the key type (we're checking for equality, not equivalence!). Very few breakages occur in qtbase. [ChangeLog][Potentially Source-Incompatible Changes] QMap does not support multiple equivalent keys any more. Any related functionality has been removed from QMap, following the deprecation that happened in Qt 5.15. Use QMultiMap for this use case. [ChangeLog][Potentially Source-Incompatible Changes] QMap and QMultiMap iterators random-access API have been removed. Note that the iterators have always been just bidirectional; moving an iterator by N positions can still be achieved using std::next or std::advance, at the same cost as before (O(N)). [ChangeLog][Potentially Source-Incompatible Changes] QMultiMap does not inherit from QMap any more. Amongst other things, this means that iterators on a QMultiMap now belong to the QMultiMap class (and not to the QMap class); new Java iterators have been added. Change-Id: I5a0fe9b020f92c21b37065a1defff783b5d2b7a9 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Remove deprecated binary json featureEdward Welbourne2020-07-311-8/+0
| | | | | | | | | Deprecated in 5.15 in favor of CBOR. Fixes: QTBUG-81239 Change-Id: I711d4bd7dd1247f58e77ac9fa53304cbe5028918 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QtCore: Use system-wide libb2 if presentLinus Jahn2020-07-311-11/+16
| | | | | | | | | | | | This adds the option to build Qt with libb2, which is especially recommended, if you care about the performance of the BLAKE2 hashing algorithms. The bundled version is the pure reference C implementation of BLAKE2, while libb2 has many additional hardware optimizations. However, the API of both is the same, so no changes to the code were necessary here. Change-Id: I3563982f4e07be300291fe103c38b16a404b3ebb Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Temporarily add a private QESDPv2Giuseppe D'Angelo2020-07-221-0/+1
| | | | | | | | | To unlock work while waiting for QISP. QESDP is lacking a few crucial APIs (isDetached() / isShared() / reset(ptr) / deep const), so we can't go there right away. Change-Id: I647eb0db4ea800488a323f3b64661e848998168d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* CMake: Get tests/auto/cmake tests workingAlexandru Croitor2020-07-171-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tests/auto/cmake project can be configured separately as a standalone project with qt-cmake, or as part of the overall qtbase standalone tests. To do that a bunch of things were done - Ported all Qt5 strings to Qt6 - Replaced in all projects the use of add_definitions and include_directories with a target based approach, except for 2 tests where we check that the old-style approach works, otherwise the tests would file - Removed some (possibly unneeded) EGL / OpenGL tests - Fixed some C++ code - Added setup code to tests/auto/cmake/CMakeLists.txt to figure out which modules are available and should be tested - Fixed Qt6CTestMacros.cmake to be loaded by Qt6Core - Removed the CMake tests to not be run in qmake builds of Qt because they would fail anyway - Enabled the CMake tests to be part of standalone tests - Disabled auto-passing of the C and CXX compiler cache vars when cross-compiling so that the tests can somewhat pass on boot2qt. This is the issue we encountered in e2b2cd9397c76e91ac1ebe493bcac7696767c02e - Ultimately disabled tests for boot2qt, because the -rpath-link flag is not generated by CMake for some reason. - Added code to setup the environment when running an executable that was built as part of the test, so that the proper Qt libraries are found. This handles both the standalone tests case and separate project case. The remaining unported tests are test_import_plugins which requires quite a bit of work to get some modules and plugins built that were done as part of the qmake .pro files, test_plugins that checks some Network plugins which I'm not sure about, and test_add_big_resource which doesn't work with namespaced builds and there's no good way of detecting those at the moment either. Change-Id: Ic8809c72817d1db81af6c6014c11df6473ad8c75 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Move QRegExp and its remaining mentions out of QtCoreSona Kurazyan2020-07-131-1/+0
| | | | | | Task-number: QTBUG-85235 Change-Id: Ibd6c98d952c1bb9916b64715c6430fb0d3fe3843 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Move all the QProperty related code into one compilation unitLars Knoll2020-07-101-1/+0
| | | | | | | | | | | | | And mark some methods as inline. Performance is critical for our new property system. Compiling it in one unit makes it possible for the compiler to do a much better job at inlining and generating optimized code. Improves performance of binding evaluations by another 20%. Change-Id: I5a2aa93c74d2b68418b0a9d2e34d8199bb71e3ad Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* Introduce QByteArrayViewSona Kurazyan2020-07-081-0/+2
| | | | | | | | | | | | | | | | | | | | Created a QByteArrayView in symmetry with QStringView. Added the basic tests symmetrical to QStringView tests. Moved the implementations of non-modifying methods of QByteArray to namespace QtPrivate, to be reused inline from both QByteArray and QByteArrayView. Changed QByteArray's counterparts of those methods to take QByteArrayView as argument instead of QByteArray. Removed QByteArray's operator QNoImplicitBoolCast(), because it was causing ambiguity when calling those methods with QByteArray argument (it was there to perevnt if(!ba)/if(ba) from compiling, but currently that would be ambiguous and won't compile anyway). [ChangeLog][QtCore][QByteArrayView] New class. Task-number: QTBUG-84321 Change-Id: I05f92e654cf65c95f2bb31b9c9018746ac110426 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Move QTextCodec support out of QtCoreKarsten Heimrich2020-06-201-51/+9
| | | | | | | | | | * Assume UTF-8 on all Unix like systems * Export some functions to be able to compile QTextCodec once moved to Qt5Compat. Task-number: QTBUG-75665 Change-Id: I52ec47a848bc0ba72e9c7689668b1bcc5d736c29 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* CMake: Provide the minimum darwin deployment target needed by QtAlexandru Croitor2020-06-191-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is useful information for people that want to use Qt in their project with CMake. Unfortunately there is no good way to actually set CMAKE_OSX_DEPLOYMENT_TARGET automatically with the Qt provided value, because it needs to be set before the first project() call in a CMake project. This means it can be set either on the command line, or manually by the application developer in CMakeLists.txt before the first project() call or via a CMake toolchain. In Qt 6 we provide a CMake toolchain file with the deployment target already set, so if the application developer uses the Qt generated toolchain, they will get the value automatically. In Qt 5 the value can only be read for informational purposes only, from the QT_DARWIN_MIN_DEPLOYMENT_TARGET property on the Qt5::Core target. The same property is set in Qt 6 for compatibility resons. Task-number: QTBUG-76167 Task-number: QTCREATORBUG-22466 Pick-to: 5.15 Change-Id: Id61d70dc9a1b7a0e7cdb90b1e679171ea178126b Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Eike Ziller <eike.ziller@qt.io>
* CMake: Fix usage of gc_binaries featureAlexandru Croitor2020-06-121-1/+1
| | | | | | | | | | | | | | | | The qt_internal_apply_gc_binaries function should apply both compile and link flags, not just link flags. The flags should be applied publically to all consumers of Bootstrap regardless if the gc_binaries feature is enabled. The flags should be applied publically to Core only in case if the feature is enabled (aka for static builds only). Change-Id: Id42af0d9b527004d74c04eff2c9e3c2be1e76aac Fixes: QTBUG-84461 Task-number: QTBUG-83929 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Include qpromise.h in corelib/CMakeLists.txtSona Kurazyan2020-06-121-0/+1
| | | | | | Change-Id: I2a854ae5774c0b98387782af685d903818475173 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* CMake: Fix libraries in qt_lib_XXX_private.pri files for NMCJoerg Bornemann2020-06-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | qmake_use.prf understands the _DEBUG and _RELEASE suffixes for QMAKE_LIBS_XXX entries. The CMake configuration "Debug" is considered for the _DEBUG entries, "Release" and "RelWithDebInfo" for _RELEASE. The qt_lib_XXX_private.pri files are now generated in multiple steps: 1. The QT_LIBS_XXX information is generated per $<CONFIG> and written to .cmake files. 2. A preliminary qt_lib_XXX_private.pri file is generated, containing only configuration-independent data. 3. A custom command runs the QtGenerateLibPri.cmake script that combines the files from step 1 and 2 into the final qt_lib_XXX_private.pri file. The same is done for mkspecs/qmodule.pri. To be able to trigger custom commands from header modules, which are interface libraries, we introduce one XXX_timestamp ALL target per header module that creates a timestamp file. To that XXX_timestamp target we add the pri file generation target as dependency. Fixes: QTBUG-84348 Change-Id: I610f279e37feeb7eceb9ef20b3ddfecff8cfbf81 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Remove winrtOliver Wolff2020-06-061-47/+29
| | | | | | | | | Macros and the await helper function from qfunctions_winrt(_p).h are needed in other Qt modules which use UWP APIs on desktop windows. Task-number: QTBUG-84434 Change-Id: Ice09c11436ad151c17bdccd2c7defadd08c13925 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* cmake: quote paths to prevent issues when no install prefix is setJean-Michaël Celerier2020-06-051-1/+1
| | | | | Change-Id: Ifa7f1ef70c4893e10cb4ce9a54d8a0806d19be93 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Regenerate src/corelibAlexandru Croitor2020-05-291-2/+2
| | | | | Change-Id: I985f9cca78e173f066d65e704c101d499668163a Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Move the UTF conversion methods to qstringconverterLars Knoll2020-05-141-0/+1
| | | | | | | | | | | | | | Separate them from the qutfcodec, so that the codec can later on be moved out of Qt Core. Fix the QUtf methods to take qsizetype instead of int for length arguments. This also makes it possible to not build QTextCodec into the bootstrap lib anymore. Change-Id: I0b4f83139d61b19c651520a2f3a5012aa7e85cb8 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* CMake: Make build system of installed Qt more relocatableAlexandru Croitor2020-05-071-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Namespace all our IMPORTED targetsJoerg Bornemann2020-04-291-2/+2
| | | | | | | | | | | CMake IMPORTED targets should be namespaced so that CMake knows that the name refers to a target and not a file. Use the existing WrapXXX naming scheme where applicable. Fixes: QTBUG-83773 Change-Id: I5b0b722c811200c56c260c69e76940a625228769 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Move Resources API into Qt6CoreMacrosLeander Beernaert2020-04-201-5/+0
| | | | | | | | Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add a public qsimd.h headerLars Knoll2020-03-261-1/+1
| | | | | | | | This header only covers a part of what qsimd_p.h does, namely the compile time detection of simd extensions. Change-Id: I05f1d987f194a5bec335f2405cc2846fbaa88b66 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Move qsimd* from corelib/tools to corelib/globalLars Knoll2020-03-261-1/+1
| | | | | | | | | | | It's not used in tools at all and fits a lot better in global. Also fix the qsimd_x86* files to have a proper copyright header. Change-Id: Id3d8e7cfcd7769a1ca9f3d8cf6d357a31a99ba40 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Introduce helper class QTaggedPointerTor Arne Vestbø2020-03-171-0/+1
| | | | | | | | | Useful for attaching small bits of information in the alignment bits of a naked pointer. For use in the new property system as well as in qtdeclarative (where currently a similar class exists as private API). Change-Id: Idf9b93e714e15129f302e16425dbeda94bcd207b Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Remove the old harfbuzz library and integration codeLars Knoll2020-03-171-11/+0
| | | | | | | | | It's not used anymore. harfbuzz-ng is a requirement in Qt 6 if you want any open type shaping. Fixes: QTBUG-82881 Change-Id: If7100aebdcfa078a999608bb8f07a2ef3a79d282 Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
* Re-generate various CMake projects and configure after mergeSimon Hausmann2020-03-161-2/+1
| | | | | Change-Id: I02f5926c6664aab518c5c81e0c33dca0818a1871 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Initial import of the Qt C++ property binding systemSimon Hausmann2020-03-161-0/+3
| | | | | | | | | | This implements the core value based property binding system with automatic dependency tracking. More features are to be added later, and the documentation will need further improvements as well. Change-Id: I77ec9163ba4dace6c4451f5933962ebe1b3b4b14 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* cmake: Regenerate projectsAlexandru Croitor2020-03-161-8/+11
| | | | | Change-Id: I0cd4f34b0df0227789805f30f474ff6aa275078f Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* cmake: Remove APPLE prefix from platform namesTor Arne Vestbø2020-03-161-10/+10
| | | | | | | None of the other platforms have it. Change-Id: Ib448c2c03ba03f711b507ef391977c0e6aa7c192 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Fix naming when referring to Apple macOSTor Arne Vestbø2020-03-161-8/+8
| | | | | Change-Id: Iafb5e448d0d65d42f788464fc600594a5666f9af Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: pro2cmake: Handle LIBS_SUFFIX define correctlyAlexandru Croitor2020-03-121-1/+1
| | | | | | | | | Matches the LIBS_SUFFIX define we use in Android conditions and replaces it with a sane amount of escaped characters. Change-Id: I7d870f992c70b105dd80b6fa94f87d3fa5644006 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Remove old 3rdparty mechanism for harfbuzz-non-ngAlexandru Croitor2020-03-101-2/+13
| | | | | | Change-Id: I37c1e561ac83c51a06aae50ccb176094785d52f5 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Remove old 3rdparty mechanism for double conversionAlexandru Croitor2020-03-101-9/+23
| | | | | | Change-Id: I2b20d4d9d95a1f7f59bc506046a1ebc20eb305f7 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Convert Core_qobject to a static moduleLeander Beernaert2020-03-051-13/+9
| | | | | | | | This removes the last add_custom_target when used in conjunction with the Ninja and CMake >= 3.17. Change-Id: Ibb9bdff4b5bc00542d2a5ba631cea7e0510ad5e9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-28 01:17:26 +0000