summaryrefslogtreecommitdiffstats
path: root/src/corelib/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* Add support for attaching continuations to QFutureSona Kurazyan2020-03-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added QFuture::then() methods to allow chaining multiple asynchronous computations. Continuations can use the following execution policies: * QtFuture::Launch::Sync - the continuation will be launched in the same thread in which the parent has been executing. * QtFuture::Launch::Async - the continuation will be launched in a new thread. * QtFuture::Launch::Inherit - the continuation will inherit the launch policy of the parent, or its thread pool (if it was using a custom one). * Additionally then() also accepts a custom QThreadPool* instance. Note, that if the parent future gets canceled, its continuation(s) will be also canceled. If the parent throws an exception, it will be propagated to the continuation's future, unless it is caught inside the continuation (if it has a QFuture arg). Some example usages: QFuture<int> future = ...; future.then([](int res1){ ... }).then([](int res2){ ... })... QFuture<int> future = ...; future.then([](QFuture<int> fut1){ /* do something with fut1 */ })... In the examples above all continuations will run in the same thread as future. QFuture<int> future = ...; future.then(QtFuture::Launch::Async, [](int res1){ ... }) .then([](int res2){ ... }).. In this example the continuations will run in a new thread (but on the same one). QThreadPool pool; QFuture<int> future = ...; future.then(&pool, [](int res1){ ... }) .then([](int res2){ ... }).. In this example the continuations will run in the given thread pool. [ChangeLog][QtCore] Added support for attaching continuations to QFuture. Task-number: QTBUG-81587 Change-Id: I5b2e176694f7ae8ce00404aca725e9a170818955 Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* CMake: Port the reduce-relocations featureJoerg Bornemann2020-02-251-1/+4
| | | | | | | | | | As reduce-relocations implies bsymbolic_functions, we also add the -Bsymbolic-functions linker flag. Also, handle the .dynlist files that are passed to the linker by bsymbolic_functions.prf in the qmake build. Change-Id: I535c33fba888596d2f8975b16864bbe9f0a7caa4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Allow building bundled 3rd party libraries in qtbaseAlexandru Croitor2020-02-251-5/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A few things are needed to accomplish that: - the python scripts do not ignore certain system_foo features anymore (it is a hardcoded list for now just to be safe) - configurejson2cmake now outputs qt_find_package(WrapSystemFoo) calls for bundled libraries (see below) - the harfbuzz .pro file is modified to accommodate pro2cmake not being able to correctly parse some conditional scopes - the freetype .pro file is modified to make sure linking of the library succeeds without duplicate symbol errors, which qmake doesn't encounter due to magical exclusion of cpp files that are included in other cpp files (presumably for include moc_foo.cpp support) - feature evaluation for Core, Gui, Network now happens in the qtbase/src directory, so that bundled libraries can be conditionally built - for each bundled library there are now two FindWrap scripts: - FindWrapSystemFoo which finds an installed library in the system - FindWrapFoo which either uses the system installed library or the built bundled one depending on a condition - projects that intend to use bundled libraries need to link against WrapFoo::WrapFoo instead of WrapSystemFoo::WrapSystemFoo targets (this is handled by pro2cmake). Unfortunately manually added qt_find_package(WrapFoo) calls might still be needed as is the case for WrapFreetype and others. - a new cmake/QtFindWrapHelper.cmake file is added that provides a macro to simplify creation of WrapFoo targets that link against a bundled or system library. The implementation is fairly ugly due to CMake macro constraints, but it was deemed better than copy-pasting a bunch of almost identical code across all FindWrapFoo.cmake files. - a qtzlib header-only module is now created when using bundled zlib, to provide public syncqt created headers for consumers that need them. These are projects that have 'QT_PRIVATE += zlib-private' in their .pro files (e.g. qtimageformats, qtlocation, qt3d, etc.) This is unfortunately needed due to QtNetwork using zlib types in its private C++ API. The change includes support for building the following bundled libraries: - zlib - libpng - libjpeg - Freetype - Harfbuzz-ng - PCRE2 The following 3rd party libraries are still using an old implementation within the CMake build system, and should be migrated to the new one in the near future: - double-conversion - Old harfbuzz The are a few libraries that are not yet ported: - system-sqlite - systemxcb - maybe others Among other things, this change allows building qtbase on Windows without requiring vcpkg. Task-number: QTBUG-82167 Change-Id: I35ecea0d832f66c1943c82e618de4a51440971a5 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
* Remove QUrl::topLevelDomainTimur Pocheptsov2020-02-201-3/+1
| | | | | | | | | | And move the actual implementation from corelib/io to network/kernel sub-module. Fixes: QTBUG-80308 Change-Id: I554b05bae3552c68e1e1a405c169366ee19120b2 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Remove QLinkedListSona Kurazyan2020-02-191-1/+0
| | | | | | | | | | | | | QLinkedList has been moved to Qt5Compat. Remove and stop mentioning it in docs, examples (the docs & examples for QLinkedList itself will be moved to Qt5Compat) and remove the corresponding tests. Also remove QT_NO_LINKED_LIST, since it's not needed anymore. Task-number: QTBUG-81630 Task-number: QTBUG-80312 Change-Id: I4a8f1105cb60aa87e7fd67e901ec1a27c489aa31 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Fix qmimeprovider_database.cpp generation for Win32 with CMakeLeander Beernaert2020-02-191-1/+1
| | | | | | | | Incorrect arguments were being passed to the command which generates the above file. Change-Id: I9f06aca30e747e4368c8f6a727a02cb93b936167 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Merge remote-tracking branch 'origin/5.15' into devLiang Qi2020-02-131-0/+1
| | | | | | | | | | | | | | | | | | | | Conflicts: examples/widgets/graphicsview/boxes/scene.h src/corelib/Qt5CoreMacros.cmake src/corelib/Qt6CoreMacros.cmake src/network/ssl/qsslsocket.cpp src/network/ssl/qsslsocket.h src/platformsupport/fontdatabases/windows/qwindowsfontenginedirectwrite.cpp src/testlib/CMakeLists.txt src/testlib/.prev_CMakeLists.txt tests/auto/corelib/tools/qscopeguard/tst_qscopeguard.cpp Disabled building manual tests with CMake for now, because qmake doesn't do it, and it confuses people. Done-With: Alexandru Croitor <alexandru.croitor@qt.io> Done-With: Volker Hilsheimer <volker.hilsheimer@qt.io> Change-Id: I865ae347bd01f4e59f16d007b66d175a52f1f152
* Refactor Metatypes dependency propagationLeander Beernaert2020-02-101-0/+9
| | | | | | | | | | | | | | | | Every metatypes.json files is now added as an INTERFACE source file to a target. This enables us later to correctly collect all the metatypes.json files from dependent targets. This information is also correctly exported via export()/install(). To avoid the metatypes.json appearing in every target's source list, the file path is wrapped in a generator expression which will only be evaluated when the consuming target has the property QT_CONSUMES_METATYPES set to true. At the moment this is limited to targets which need to interact with qmltyperegistrar. Change-Id: I0ffebcd069a923383f7ed11cde2c94ecf2fb13f3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Allow manually specification of moc.json files for metatype generationLeander Beernaert2020-02-051-3/+18
| | | | | | | | | | | | | | qt6_generate_meta_types_json_file() has been extended to allow the generated moc_....cpp.json files to be manually specified. This now enabled the metatype generation to be used without resorting to AUTOMOC. Additionally, Core_qobject declaration order has been temporarily moved as it otherwise does not produce the correct metatypes dependency file for Core. This will be fixed in a follow up patch. Change-Id: I3266ab3073db478458a0c1dbc8b9fbab16622a64 Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Post-merge fixesAlexandru Croitor2020-01-301-8/+5
| | | | | Change-Id: I6acd29103f6cc550544e7422328d97ea0e2dcafb Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-29 07:55:51 +0000