summaryrefslogtreecommitdiffstats
path: root/src/entrypoint
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Fix undefined reference to WinMain errors with MinGWJoerg Bornemann2021-10-282-6/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | When linking against Qt with MinGW, libmingw32.a must come before libQt6EntryPointImplementation.a on the linker command line. Otherwise the linker cannot find the WinMain symbol that's defined in the EntryPointImplementation library. Under certain circumstances, mingw32 was linked after EntryPointImplementation. To reliably ensure the order of said libraries, we introduce the imported library EntryPointMinGW32. This target represents libmingw32.a and links against EntryPointImplementation. The link dependencies look like this: EntryPointPrivate -> EntryPointMinGW32 -> EntryPointImplementation The imported library EntryPointMinGW32 is defined in a separate .cmake file which is included by both src/entrypoint/CMakeLists.txt and Qt6EntryPointConfig.cmake. This is needed, because the consumer outside of Qt must access this imported library, and we cannot export imported libraries. Pick-to: 6.2 Fixes: QTBUG-93671 Change-Id: Ib3c5e80cbcc9c793d000e5ad637325bcf735a1ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Adjust the EntryPoint target name according to the internal module naming policyAlexey Edelev2021-06-151-13/+19
| | | | | | | Pick-to: 6.2 Task-number: QTBUG-87775 Change-Id: I1d6097c950f97e102c44e2952edc98caa4deb6c6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix qmake user projects for QT_LIBINFIX builds on Windows/iOSJoerg Bornemann2021-03-171-1/+1
| | | | | | | | | | | | QMake user projects could not be built on Windows or iOS if Qt was configured with QT_LIBINFIX set. The code that generates qt_lib_entrypoint_private.pri file did not take into account the lib infix. Pick-to: 6.1 6.0 Fixes: QTBUG-91511 Change-Id: Ibc40548a269238320f8f89a710d10e7f639246cb Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Generate Qt6EntryPointAdditionalTargetInfo independent of platformAlexey Edelev2021-01-201-7/+10
| | | | | | | | | | | Move AdditionalTargetInfo generation for EntryPoint target out of WIN32 specific block Fixes: QTBUG-90414 Change-Id: I8dc34c939f12ef2073de630d4440a0892d8be909 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 32734f351b076b8774c490c27ef18ddd2243dcaf) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* QtEntryPoint: Fix linking Release against RelWithDebInfo with MSVCJoerg Bornemann2021-01-181-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | To be able to link a Release user project against a RelWithDebInfo Qt we set several IMPORTED_*_RELEASE properties in the *AdditionalTargetInfo.cmake file of each Qt module. The EntryPoint module however is a bit special as it is an INTERFACE_LIBRARY linking publicly against a static library (EntryPointimplementation). Its *AdditionalTargetInfo.cmake file was almost empty, because qt_internal_export_additional_targets_file was called before EntryPointImplementation was set up. Also, qt_internal_add_module, which calls qt_internal_export_additional_targets_file, does not know that we want to export the EntryPointImplementation target. We fix this by telling qt_internal_add_module(EntryPoint) to not generate the *AdditionalTargetInfo.cmake file and call qt_internal_export_additional_targets_file later to take the targets EntryPoint and EntryPointImplementation into consideration. qt_internal_add_module learned the option NO_ADDITIONAL_TARGET_INFO to turn off the generation of *AdditionalTargetInfo.cmake files. Pick-to: 6.0 Fixes: QTBUG-90039 Change-Id: I68ec7125b538a57567035e7adb8dac3b213f95e6 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Prevent compiler and linker flags from growing every cmake runCraig Scott2021-01-151-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Functions in QtFlagHandlingHelpers.cmake try to update the CMake cache variables for compiler and linker flags. These were using the current value of those variables and writing the modified ones back to the cache every time CMake ran. If a toolchain file sets or modifies any of these variables, that updated value is used and written back into the cache instead of the original cache variable's value. The next time CMake executes, the toolchain file re-applies the same change and the variable grows longer each time with flags repeated. With Ninja, this causes a complete rebuild every time CMake is re-run. The Android NDK toolchain file is one example where this behavior is triggered (the fault is shared, one could argue that the NDK should only be setting ..._INIT variables, but that's out of our control). Another related bug in the previous implementation was that the flags used to build after the first CMake execution could be different to those used for all builds after the second and later CMake runs. This is because the CMake cache was being updated, but not always the calling scope of the functions that modified them. If a toolchain file set any of the compiler or linker flag variables as non-cache variables, then updating the cache variable would have no effect on the calling scope. The non-cache variable would continue to take precedence for that scope for that run. The next time CMake executes though, the updated cache variable would now have been used by the toolchain file and the change *will* be part of the non-cache variable's value. The above are examples of why you should try to avoid updating these cache variables from project code. We could leave the cache alone and always update only non-cache variables, but then a developer looking at the cache may wonder why the values they see there don't match the values being used in builds. Or worse, they think the cache values are being used and don't realize the builds are using something different. Ultimately, we have to choose which downside we are happy to live with. The changes here preserve the previous intent of updating the cache, but it's still a bit fragile. Fixes: QTBUG-89821 Task-number: QTBUG-85992 Task-number: QTBUG-86866 Change-Id: I8a16753e159bde338e6d2e5dd2ce91fc8ac5c39d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Remove the qmake project filesJoerg Bornemann2021-01-073-88/+0
| | | | | | | | | | | | | | | | Remove the qmake project files for most of Qt. Leave the qmake project files for examples, because we still test those in the CI to ensure qmake does not regress. Also leave the qmake project files for utils and other minor parts that lack CMake project files. Task-number: QTBUG-88742 Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* CMake: Fix compile warnings when MSVC and -DFEATURE_static_runtime=ONLi Xinwei2020-12-151-0/+1
| | | | | | | | | | | | | When using MSVC compiler and -DFEATURE_static_runtime=ON, qrc_foo.cpp and qtentrypoint_win.cpp are still compiled with '-MD' or '-MDd' flag, which will cause following warnings and other possible problems: warning LNK4098: defaultlib "MSVCRT" conflicts with use of other libs; use /NODEFAULTLIB:library Pick-to: 6.0 Change-Id: I6794930a64e9cff4dc1c9632fc3fc64227848af0 Reviewed-by: Yuhang Zhao <2546789017@qq.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix entrypoint output directory when multi-config buildLi Xinwei2020-11-231-0/+1
| | | | | | | | | | | When multi-config build, the output directory of Qt6EntryPoint.lib is <build_dir>/lib/Release, the output directory of Qt6EntryPointd.lib is <build_dir>/lib/Debug. This behavior is different from other lib files. Both release and debug lib files should be outputted to <build_dir>/lib. Pick-to: 6.0 Change-Id: I81d284e4630afebb40ba90fe822dd5bda2b2036a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Remove indirection via Startup target for EntryPointTor Arne Vestbø2020-11-121-7/+7
| | | | | | | | | | | | | The EntryPoint interface target now contains all the logic for what flags and optional static libraries to add when the entrypoint is enabled. The target property QT_NO_ENTRYPOINT can be used to disable the entrypoint. Change-Id: I9b14ff729366cd6307789c969ebd4b2ca19de77d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Move iOS entrypoint logic to entrypoint libraryTor Arne Vestbø2020-11-103-44/+73
| | | | | Change-Id: Ie0fc8368953a59d06a31847ed417bc3c35f29b90 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Remove custom logic for writing entrypoint implementation priTor Arne Vestbø2020-11-102-21/+15
| | | | | | | | | | | | Trying to keep the logic self-contained resulted in a race condition during 'make install', even if the two sub projects were CONFIG+=ordered. The approach is now similar to what we have on the CMake side, where the ldflags and defines end up in the 'interface' module. Change-Id: Id08a3ca12da8e7fc36ad76124b52ca4c79aebe3b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Don't rely on the module.pri for the entrypoint linking to the libraryTor Arne Vestbø2020-11-094-46/+89
| | | | | | | | | | | | | | | | Depending on the presence and behavior of HEADER_MODULE/header_module in CMake and qmake land, the module.pri might end up with an empty module line, which means adding the module via QT_PRIVATE += entrypoint will not link to the static library. To avoid this problem we write an explicit module entry (QT.foo.bar) into the same module.pri file as the one generated by qt_module, where the auto-generated one has header_module enabled, and hence no link behavior, while the manually written entry has a module component, and will ensure linkage to the static library. Change-Id: Ib98484f74410fab45c4d109f3610028200fba0c5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Allow adding linker flags to qmake module prisTor Arne Vestbø2020-11-032-2/+14
| | | | | | | | | | | | | The flags go before the library in the final linker line, as opposed to the dependencies declared in LIBS. This allows us to declare the flags for the entrypoint in the project file of the entrypoint, instead of in a standalone prf. Change-Id: I35c054fe9fdaa6add7cd0e8ba3f7304f975ff80f Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Add missing aliases for entrypoint implementationTor Arne Vestbø2020-10-281-0/+2
| | | | | Change-Id: I2fda3a84ca2d12f74b68a8bbe6c6ae9cd04b5aea Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Ensure Mingw builds pick up and use the WinMain entry pointTor Arne Vestbø2020-10-261-21/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The cmake code path didn't export QT_NEEDS_QMAIN as a public define to be inherited by consumers. As a result, the users's main() would be defined as normal (instead of being named qMain). This in turn would lead mingw to pick main() as the entrypoint during link time. We want to go through our WinMain entrypoint (for now), even if MingGW today has mechanisms for calling the user's main() directly, as our WinMain uses GetCommandLineW() and as a result prevents the arguments to main() from being wildcard expanded. and we want to keep parity between qmake and CMake in how this behaves, even if we end up changing it in the future. We follow what qmake does, and expose QT_NEEDS_QMAIN to clients. With the user's main being then named qMain, mingw will look for our WinMain. This in turn leads to the problem of static link ordering, where adding -lmingw32 as a dependency of the static library target results in it ending up _after_ the static library during link time, and the static linker ends up discarding the entry point library. To solve this, we split the entry point module into two targets, one for consumers, and one internal that is the actual static library. By adding the -lmingw32 dependency to the former target, we ensure it's added before the static library during linking. Change-Id: I342c979f56669d5a5a5c237f476556c4e2baf432 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Make entry point module an internal moduleTor Arne Vestbø2020-10-232-1/+3
| | | | | Change-Id: I9eaadc7ce8ca03d64ff3a33c7b6641b073570a61 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix linking of non-console application on mingwTor Arne Vestbø2020-10-201-1/+0
| | | | | | | | | | | | As a result of b5af1408099d the link dependency to the mingw32 static library was ordered after the entrypoint library, which resulted in the WinMain symbol not being found during linking due to how the static linker processes archives. Fixes: QTBUG-87725 Change-Id: I8e075f91f7f06dcdc618a4e0ae6d9c1d832888c0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Generalize the winmain/qtmain entry-point libraryTor Arne Vestbø2020-10-173-0/+165
The use-case is relevant for other platforms as well. Now that Qt has a module system we can also replace a lot of the hand crafted logic for linking with simpler constructs. Change-Id: Ib6853aaf81bfea79c31f2de741d65b4b56f23ef6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-30 14:10:06 +0000