summaryrefslogtreecommitdiffstats
path: root/src/entrypoint
Commit message (Collapse)AuthorAgeFilesLines
* Generate Qt6EntryPointAdditionalTargetInfo independent of platformAlexey Edelev2021-01-201-7/+10
| | | | | | | | | | Move AdditionalTargetInfo generation for EntryPoint target out of WIN32 specific block Fixes: QTBUG-90414 Pick-to: dev Change-Id: I8dc34c939f12ef2073de630d4440a0892d8be909 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* 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. Fixes: QTBUG-90039 Change-Id: I68ec7125b538a57567035e7adb8dac3b213f95e6 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> (cherry picked from commit b0add5bf2f56c2afc8bdf27ccbb153414617250b) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* CMake: Fix compile warnings when MSVC and -DFEATURE_static_runtime=ONLi Xinwei2020-12-171-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 Change-Id: I6794930a64e9cff4dc1c9632fc3fc64227848af0 Reviewed-by: Yuhang Zhao <2546789017@qq.com> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 21e4e85a5798884837b35859f73f1eca4cb976d2) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* 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. Change-Id: I81d284e4630afebb40ba90fe822dd5bda2b2036a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 876b22a425aea45023983aae584eb9996886467f) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* 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-05-07 21:53:27 +0000