This way we don't need to run rcc during cmake time
Change-Id: Id92111bce6c2b6798f3b18552cea82c8d07c4fc0
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Also make the tool package depend on all tool packages that correspond
to the qt module dependencies.
So find_package(Qt5Widgets) implicitly calls find_package(Qt5WidgetTools).
And find_package(Qt5WidgetsTools) will call find_package for
Qt5GuiTools, and Qt5CoreTools.
This enhances the user experience, so that in modules like qtsvg, you
don't have to specify both find_package(Qt5Widgets) and
find_package(Qt5WidgetsTools), but only the former.
Or when cross building, you only need to specify Qt5WidgetTools, to get
both Core and Gui tools.
Change-Id: Ib1c5173a5b97584a52e144c22e38e90a712f727a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This change introduces a new function called qt_find_package()
which can take an extra option called PROVIDED_TARGETS, which
associates targets with the package that defines those targets.
This is done by setting the INTERFACE_QT_PACKAGE_NAME and
INTERFACE_QT_PACKAGE_VERSION properties on the imported targets.
This information allows us to generate appropriate find_dependency()
calls in a module's Config file for third party libraries.
For example when an application links against QtCore, it should also
link against zlib and atomic libraries. In order to do that, the
library locations first have to be found by CMake. This is achieved by
embedding find_dependency(ZLIB) and find_dependency(Atomic) in
Qt5CoreDependencies.cmake which is included by Qt5CoreConfig.cmake.
The latter is picked up when an application project contains
find_package(Qt5Core), and thus all linking dependencies are resolved.
The information 'which package provides which targets' is contained
in the python json2cmake conversion script. The generated output of
the script contains qt_find_package() calls that represent that
information.
The Qt5CoreDependencies.cmake file and which which dependencies it
contains is generated at the QtPostProcess stop.
Note that for non-static Qt builds, we only need to propagate public
3rd party libraries. For static builds, we need all third party
libraries.
In order for the INTERFACE_QT_PACKAGE_NAME property to be read in any
scope, the targets on which the property is set, have to be GLOBAL.
Also for applications and other modules to find all required third
party libraries, we have to install all our custom Find modules, and
make sure they define INTERFACE IMPORTED libraries, and not just
IMPORTED libraries.
Change-Id: I694d6e32d05b96d5e241df0156fc79d0029426aa
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
CMake will now generate config and target files for each module that
provides tools. As a result, namespaced global targets such as
Qt5::moc or Qt5::rcc can be made available.
Third party projects that require just these tools, and not the Qt
modules themselves, should specify CMAKE_PREFIX_PATH pointing to the
installed Qt location, and call find_package(Qt5CoreTools),
find_package(Qt5GuiTools), etc.
It is also possible to call
find_package(Qt5Tools REQUIRED Core Widgets) where the last option
is a list of modules whose tools should be imported.
Note that all the tools are in the Qt5::
namespace and not in the Qt5CoreTools:: or Qt5WidgetsTools::
namespace.
This commit also changes the behavior regarding when to build tools
while building Qt itself.
When cross compiling Qt (checked via CMAKE_CROSSCOMPILING) or when
-DQT_FORCE_FIND_TOOLS=TRUE is passed, tools added by add_qt_tool will
always be searched for and not built.
In this case the user has to specify the CMake variable QT_HOST_PATH
pointing to an installed host Qt location.
When not cross compiling, tools added by add_qt_tool are built from
source.
When building leaf modules (like qtsvg) that require some tool that was
built in qtbase (like moc), the module project should contain a
find_package(Qt5ToolsCore) call and specify an appropriate
CMAKE_PREFIX_PATH so that the tool package is found.
Note that because HOST_QT_TOOLS_DIRECTORY was replaced by QT_HOST_PATH,
the ensure syncqt code was changed to make it work properly with
both qtbase and qtsvg.
Here's a list of tools and their module associations:
qmake, moc, rcc, tracegen, qfloat16-tables, qlalr -> CoreTools
qvkgen -> GuiTools
uic -> WidgetTools
dbus related tools -> DBusTools
Task-number: QTBUG-74134
Change-Id: Ie67d1e2f8de46102b48eca008f0b50caf4fbe3ed
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Update required dependencies.
Add section on how to build vcpkg on macOS.
Fix some typos.
Lower required CMake version.
Inform how to bypass annoying ninja reconfiguration issue.
Change-Id: Ia35bd4329c2cbb9857157cdc33b098f5adb04a35
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
With qmake if we don't find a system package, we use the bundled one.
With CMake we don't provide a bundle freetype, hence it's required
to find a system one (or custom provided one).
Change-Id: I00a5e2ac55459957dae0729f89bafa792a102152
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Otherwise add_qt_executable will still link against Core,
and thus building qmake in a static build will fail.
Amends a1752276e0
Change-Id: Iebbdf9d0a2808a9eaeffdf8fbdb44ff5e2920f3b
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Qmake should not rebuild all the code in QtCore, but currently it does.
When linking against QtCore, all the symbols get duplicated. A clever
linker will "deduplicate" the symbols again, so this actually works
with shared Qt builds, but it fails for static builds.
Do not rely on the linker being clever and just do not link Qt at all
for qmake.
Change-Id: I0f79ed9176a19ee884dd425e5f23c26cf69dc422
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
When building qtsvg, the file gets picked up while doing
find_package(Qt5Gui) and fails the configuration phase.
Remove it as it was done before.
Change-Id: I3499e33ecc129e31f8d3b144ee6370b2a9bb4f9a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Use absolute paths for source files, and relative paths plus a correct
working directory for output files.
This is required to work around a limitation of the dbusxml2cpp tool
where it splits a command line option on a colon ":". Windows paths
contain colons, and that breaks the internal logic of the tool when
passing absolute paths.
Change-Id: Ic653f1317ae4f68bb2f488c117fe48c34310c76e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Applications that have the WIN32_EXECUTABLE property set,
must have a WinMain function. In qmake's case, this function
is provided by the qtmain static library.
Until that is implemented in CMake land, disable the property on
Windows for all qt executables. This fixes the linker issues while
building examples.
Task-number: QTBUG-75195
Change-Id: I323d4dd899f716cd6b9b7f4b5ecb76b22f462fc4
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Add a test that checks for the Presence of Qt for Python
and runs Python compile tests on the baseline files.
Task-number: PYSIDE-797
Change-Id: I7e15c3c75261a7d94fc6654a95d49ba323cbe7d6
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
This patch ensures that installed files are written to physical disk
before the 'cache.version' file is written.
QtLoader.java uses the 'cache.version' file written during
self-installation to indicate whether re-installation is necessary.
The 'cache.version' file, however, was being written at the start of
installation, so its existence merely indicated that the installation
was attempted. In the case of power loss during installation, the
existence of 'cache.version' would prevent retrying installation on the
next launch, so the bad installation was irrecoverable.
[ChangeLog][Android] Fixed an issue where an application installation
would be irrecoverably broken if power loss or a crash occurred during
its first initialization run.
Fixes: QTBUG-71523
Change-Id: If771b223a0a709a994c766eea5a4ba14ae95201e
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
This automatically searches for some default devices. This not only
reduces the amount of code, it also makes sure that Qt will by default
find the same input devices that tslib (e.g. ts_calibrate) will find.
Fixes: QTBUG-74680
Change-Id: Ied3fff7e8ed9d6637d2b8cf32119660133d251a3
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Qt 5.12 comes with xkbcommon_support now. Map that accordingly.
Change-Id: Id10708349d377f6bdfed654428ebcef0b533bd69
Reviewed-by: Albert Astals Cid <albert.astals.cid@kdab.com>
Unfold the function with returns to reduce nesting and add language
handling.
Task-number: PYSIDE-797
Change-Id: Ie6c47745b118d75c0bb2c9eea7d52c8f0377f1a6
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
Handle dlopen properly. Code is ifdef-ed on it, so we need it:-/
Change-Id: I7f35d24b97530796a4cdcdc1acbe139757170215
Reviewed-by: Albert Astals Cid <albert.astals.cid@kdab.com>
Use an imported target to create _nolink targets. This gets rid of
the need to have an helper target that gets aliases to get work
around the problem of the original target might having a "::" in
its name.
Change-Id: I4618980cf2c673ebf5caca593bccf122b3c81480
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Usually, when you load a plugin, you don't want to load just any plugin
that fulfills a given interface, but rather a specific one. When loading
dynamic plugins you can differentiate the plugins by file name. This
doesn't work in the static case, and file names are also separate from
the plugin metadata shipped inside the plugin files.
To solve this problem, different hacks have been developed in various
places. QML extension plugins add a special property "uri" via the -M
option of moc, QML debug plugins expect you to add a json file with
an array of "Keys", Qt Creator plugins have a "Name" in their json
files, etc.
By allowing the identifier for the plugin to be specified inline with
the metadata declaration we can make many of the above workarounds
obsolete and provide a clean way for users to find their plugins.
Task-number: QTBUG-74775
Change-Id: Ie2af16c49d4c5aa5a77fab0fae1e0a4449bd7a39
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Skip based on support for window activation instead of platform. Makes it clear
why the tests are skipped, and also enables them automatically if we implement
a shell extension that adds support for it.
Task-number: QTBUG-66849
Change-Id: I322aba5ce5f8db651db7b71f223ffacec037c920
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
QCollator was using the default-constructed QLocale() as its default;
this locale's default was the system locale; however, that didn't pay
any attention to system settings for collation such as Unix's
environment variable LC_COLLATE or the MS-Win LOCALE_SSORTLOCALE
configuration option.
Teach the system locale back-ends to look up their relevant settings,
add QLocale::collation() as a channel via which to access that and
change no-parameter construction of QCollator to a separate
implementation (rather than the constructor taking QLocale having a
default) using it.
[ChangeLog][QtCore][QLocale] The system locale now knows what to use
for collation, QLocale::system().collation().
[ChangeLog][QtCore][QCollator] The default QCollator now uses the
system's collation locale, rather than the system locale itself.
Fixes: QTBUG-58621
Change-Id: I90f86621541385330315d1f9d6a4b982bdcea9d5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add a helper function to QtBuild that generates Foo_nolink versions
of Foo library targets.
Map 'Foo/nolink' libs found in qmake to Foo_nolink.
Automatically run helper function to create _nolink targets as
part of extend_target.
Change-Id: I4c23ea68b3037d23c9a31d4ac272a6bd0565f7c0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Clang-cl couldn't find the header given to it by -FI when it isn't in
any of the included directories.
Additionally clang-cl 8 has a bug with exported templated classes with
inline methods that causes it to have missing symbols at link time. We
work around this.
Fixes: QTBUG-74563
Change-Id: I7becf05fa8edb07bd4cefe12bee3737e5e1dfa14
Reviewed-by: Yuhang Zhao <2546789017@qq.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Include many headers that are commonly used now, and avoid listing them
twice.
Change-Id: I679dc24cff2cb3a3c9c18585ec78007ab3550743
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QTableView drew additional grid lines on the top and left side when
the corresponding header was not visible and the ScrollMode was
ScrollPerItem. After 8f2bacea41 they were
also drawn for ScrolPerPixel for consistency. But they are not needed at
all and only create visual artifacts.
Therefore remove the drawing of the additional lines completely.
Fixes: QTBUG-74706
Change-Id: I5c77d53a2eeefab9b9bfe0efea6439f5afede4ac
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Ctrl+End moves the visual index to the bottom left index. This does not
work correctly when the item in the bottom left is disabled. It should
be fixed with 7863be3115 but does not due
to a typo.
Fix the typo by using the newly calculated visualColumn instead the
initial column.
There are cases where the algorithm still does not work as expected when
there are more disabled items but fixing them would add a lot of
complexity with no (much) gain.
Fixes: QTBUG-72400
Change-Id: Ie90f6b3e41e00f54e826c2b4e7303e85ac1e4115
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
QMetaObject::newInstance returns a QObject, thus it's not possible to
create a new instance of a Q_GADGET using this function. Previously, we
returned a non-null QObject pointer for such scenarios, which then
leads to crashes when one tries to use it. Now, we check whether the
meta object inherits QObject's meta object, and error out early
otherwise.
Change-Id: I7b1fb6c8d48b3e98161894be2f281a491963345e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The first replacement had missed objective-C++ code some places ourside
the src dir.
In C-files Q_DECL_NOTHROW is replaced with Q_DECL_NOEXCEPT as we still
need to turn it off when compiled in C mode, but can get rid of the old
NOTHROW moniker.
Change-Id: I6370f57066679c5120d0265a69e7e378e09d4759
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
