| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
| |
Change-Id: Ie0fc8368953a59d06a31847ed417bc3c35f29b90
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
| |
Change-Id: I2fda3a84ca2d12f74b68a8bbe6c6ae9cd04b5aea
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
| |
Change-Id: I9eaadc7ce8ca03d64ff3a33c7b6641b073570a61
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
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>
|
