It is shared between car and controller executables.
Task-number: QTBUG-111366
Pick-to: 6.5
Change-Id: I5f98a09664671c55bfad68ebf88c9f0c734511fa
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This allows building of all the example executables at once.
Task-number: QTBUG-111366
Pick-to: 6.5
Change-Id: I1fa372ec9725bfeb1f123305aa7324b7820eb593
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Use WEBP format to reduce the file size.
Task-number: QTBUG-111366
Pick-to: 6.5
Change-Id: I14ff15010e7ac7e1b375eeafaa1c153b0fdd95e6
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
We (almost) only build apps, for which PRIVATE linkage makes more sense.
Change-Id: I09a509c3fb33a00cdfdede687b3f95d638f42091
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
This is what we promote also in the documentation.
Change-Id: If91aebafe861b0c934acbb2c69afd182abc3345d
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
CMAKE_INCLUDE_CURRENT_DIR is not necessary anymore for moc since
CMake 3.8: https://cmake.org/cmake/help/latest/release/3.8.html#other-changes
CMAKE_AUTORCC should not be used anymore. Instead, we now use
qt_add_resources() or similar
Enable CMAKE_AUTOUIC only if .ui files are present.
Pick-to: 6.3
Task-number: QTBUG-87643
Change-Id: I835e2994cd5dba9918136999499b9077961b616c
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Also consolidate several find_package(Qt6 ...) calls in one call.
Task-number: QTBUG-98867
Change-Id: Idfd5e71f46d4489fac7411cbfadb84437a0658f3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
These are left-overs from the initial qmake2cmake conversion.
Pick-to: 6.2
Change-Id: Ie15c9ff022ea4566d10c1ba74599de9af83d29a7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This file was necessary for the qmake build and the CI. The qmake
build is history, and the CI does now read .cmake.conf (see
QTQAINFRA-4392).
In addition to being superfluous, the existence of .qmake.conf
triggers QTBUG-76140 when building Qt examples with qmake. Removing
the file alleviates the symptoms of this bug.
"Interestingly", to make the qmake build of examples work in the CI, we
have to adjust the dbus examples to not use nmake inference rules. The
absence of .qmake.conf results in a different order of inference rules
in the Makefile, and nmake/jom pick up generated source files from the
source dir. These are incompatible with the correct generated source
files in the build dir. See QTBUG-96513 for details.
Fixes: QTBUG-92271
Task-number: QTBUG-96513
Change-Id: I4076fae2eeb993956b54aced2c9c844ae2577a4a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Examples are intended to show how to build against an installed Qt.
Building them as part of the main build means the way the Qt targets
are defined and created are not representative of an end user's build.
By building them as separate projects using ExternalProject, we can
more closely replicate the intended audience's environment. This
should allow us to catch more problems earlier.
Having examples built as part of the main build also creates problems
with some static builds where a tool built by the main build is needed
during configure time. This happens with other repos like qtdeclarative
but not (currently) with qtbase. Converting the examples in qtbase to
be built using ExternalProject is intended as a demonstrator for how
other repos can do similar. Until other repos are converted, they will
continue to work as they did before, with examples as part of the main
build for non-static builds only.
The new build-externally behavior is only supported for non-prefix
builds with this change. Prefix builds will continue to use the old
non-external method. Support for building examples externally in
prefix builds will be a separate change.
Task-number: QTBUG-90820
Fixes: QTBUG-91068
Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Per the discussion of QTBUG-88831, we determined that module-wide
imports are unfortunate, especially for compile times. Following this,
all QtDBus includes have been replaced with the headers for the classes
actually used in each file. Additionally, some cleanup of header file
order and format has been performed in the changed files.
Pick-to: 6.0
Change-Id: I62c1b75682a48422f0ba1168dd5d7bd0952808ac
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Similar to what has been done in 5138a970f3, we need to adjust the
remotecontrolledcar/controller dbus example to be built with qmake.
In the CI we first build the examples with CMake in the source
directory. That creates some generated source files in the dbus example
dir.
Then, the examples are (will be) built ouf of source with qmake, and
those generated source files will be placed in the build directory.
When building with MSVC, there's a peculiarity with nmake/jom's
inference rules that lead to picking up the generated car_interface.cpp
from the source directory, instead of the build directory.
See QTBUG-13496 for details.
car_interface.cpp, built with CMake is generated to include
car_interface.moc.
car_interface.cpp, built with qmake does not have this include, but the
build system calls moc on car_interface.h.
All this leads to duplication of the meta object for
OrgExampleExamplesCarInterfaceInterface, preventing successful linking.
Work around this issue by turning off the generation of nmake/jom
inference rules.
Task-number: QTBUG-85986
Change-Id: I0a6ca9f880b63f05a4e9f2032e44d3b391d8a756
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
As well as the MACOSX_BUNDLE properties as necessary.
Task-number: QTBUG-87664
Task-number: QTBUG-86827
Change-Id: I7677449a26d51fa853bd67bab6b3b61afbd2b12f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This time based on grepping to also include documentation, tests and
examples previously missed by the automatic tool.
Change-Id: Ied1703f4bcc470fbc275f759ed5b7c588a5c4e9f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
While trying to implement instructions for building examples with
qmake in the CI, an issue has surfaced.
When building examples with CMake with -DBUILD_EXAMPLES=ON in the CI,
the examples are built in-source, aka source dir == build dir.
This means that the header files generated by qdbusxml2cpp will be
placed in the qtbase source dir.
The instructions that try to build examples with qmake build the
examples in a separate build dir after building the examples with CMake.
Unfortunately the qtbase/examples/dbus/remotecontrolledcar/car example
includes the generated DBus adaptor header via a statement like
#include "car_adaptor.h"
and the compiler prefers to pick up the header file from the example
source dir (the one generated by CMake), rather than the one generated
by qmake in the example build dir.
Because CMake's DBus integration uses different flags than qmake's
DBus integration, the generated header file code is not compatible
with the qmake generated cpp file, and the example fails to link when
building with qmake, because it can't find an appropriate constructor
symbol.
In an ideal world, we wouldn't do in-source builds with the CMake
build, but that leads to other issues which I currently don't recall.
To circumvent the issue, adapt the CMake DBus qt6_add_dbus_adaptor
function to allow not passing the problematic '-l' flag by making it
optional. This shouldn't break existing code, but allows us to
generate a compatible header that will be used by qmake and succeed in
linking the example.
Task-number: QTBUG-85986
Change-Id: I06759f79aeb66bb32da7f158f55dd4734c4a9887
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Update all public Qt macros to use qt6/QT6 instead of qt5/QT6.
Change-Id: Ib178f4fa21f37dfb8da7d4d8c097aa0e96c9d9f9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This changes many different CMake places to mention Qt6 instead of
Qt5.
Note that some old qt5 cmake config files in corelib are probably not
needed anymore, but I still renamed and kept them for now.
Change-Id: Ie69e81540386a5af153f76c0242e18d48211bec4
* Simplify add_qt_gui_executable() to not require WIN32/MACOSX_BUNDLE
but provide it implicitly. It's redundant :)
* When on Android, build a module (shared library), just like qmake.
This requires an additional library destination in the install() call,
but that's ignored on other platforms.
* Fix typos in the android deployment generation settings function
* Use the correct cache variable to determine whether we're inside a Qt
build or not. Right now this only works inside Qt builds anyway as
QtPlatformAndroid.cmake is not publically accessible.
Change-Id: If1c763c31a7a83d0e0d854362ba7901657f63eb5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
Provide add_qt_gui_executable() as function in our public API that takes
care of automaticWinMain linkage. We can use this in the future to
encapsulate similarplatform-specific behavior and adjustments, such as
module generation onAndroid.
In order for the examples to see the function in Qt5CoreMacros, three more
additional fixes were required:
* Do the build_repo_end() call _before_ attempting to build the
examples, as we need the build_repo_end() to include QtPostProcess
and complete the creation of all the target config files.
Otherwise the find_package() calls in the examples see something
incomplete.
* Add more QT_NO_CREATE_TARGET guards
* Always call find_dependency on the dependencies, regardless of the
target creation mode. This way a find_package(Qt5 COMPONENTS
Widgets) will still load Qt5CoreMacros.
Change-Id: I03ce856e2f4312a050fe8043b8331cbe8a6c93e6
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Create CMake config files which can be used from the very same CMake
project. These CMake config files simply do not create any targets,
controlled via the QT_NO_CREATE_TARGETS.
This patch also allows to build qtbase.git:examples as a standalone
project, against an already-built Qt.
Ran this:
ag -s "QT " examples -l -0 | xargs -0 -n 1 .../util/cmake/pro2cmake.py --is-example
Task-number: QTBUG-74713
Change-Id: I44cce5a4048618b30f890c5b789592c227a8b47d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Especially in examples, where we should show off our convenience
functions, prefer calling these functions over doing arithmetic with
M_PI (or approximations thereto) and 180 (give or take simple
factors). This incidentally documents what's going on, just by the
name of the function used (and reveals at least one place where
variables were misnamed; the return from atan is in radians, *not*
degrees).
Task-number: QTBUG-58083
Change-Id: I6e5d66721cafab423378f970af525400423e971e
Reviewed-by: Jüri Valdmann <juri.valdmann@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Update files using old header.LGPL3 to header.LGPL
Update files using old FDL template to use new one
Update files using old BSD template to use new one
Change-Id: I36a78272516f9953d02956522f285b40adfc8915
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
-transferred group page from qtdoc repository
-added description in example pages
-set the example documentation to use the standard Qt thumbnail
-added an entry in the help index for the example page
Change-Id: I9d5747bc329b5ecc15acd2eb3139696931166c6f
Reviewed-by: Topi Reiniö <topi.reinio@digia.com>
The Qt Simulator is no longer supported with Qt 5.
Change-Id: I0f98351d482dd0554ea0754746d56f94ee6bf22f
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Modularized example paths are defined in module-specific .qdocconf
files. This change fixes \example command for a number of examples to
be relative to those paths. This way, the manifest files will have a
correct project path for each example.
Change-Id: I6d3dba34a1eb04a2bc294520102e232ccd0f0ba2
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
it's confusing for the users if the examples' project files contain code
to install their own sources. also, this constitutes an enormous code
duplication, and lots of mistakes. consequently, automate it.
more or less as a side effect, this also removes the entirely meaningless
target installs in subdirs projects.
Task-number: QTBUG-28184
Change-Id: I9fc1367a06db9e2c46aeb67d68729a4f67163ef9
Reviewed-by: hjk <qthjk@ovi.com>
they were added without an explanation, and they can't be particularly
useful (because they contain hard-coded paths and refer to non-existing
icons).
Change-Id: I27e2c35375e28645b0c03449ddc7ac7017da5943
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
This makes the structure of the examples after an 'make install'
similar to the one in a 'developer build'.
Change-Id: I9120bd741fab332e64e30adc01cefe87e5633454
Reviewed-by: Martin Smith <martin.smith@digia.com>
