Since we also license under GPL-3.0 WITH Qt-GPL-exception-1.0,
this applies only to a hypothetical newer version of GPL, that doesn't
exist yet. If such a version emerges, we can still decide to relicense...
While at it, replace (deprecated) GPL-3.0 with more explicit GPL-3.0-only
Change was done by running
find . -type f -exec perl -pi -e "s/LicenseRef-Qt-Commercial OR GPL-3.0\+ OR GPL-3.0 WITH Qt-GPL-exception-1.0/LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0/g" {} \;
Change-Id: I5097e6ce8d10233993ee30d7e25120e2659eb10b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Task-number: QTBUG-67283
Change-Id: I708fd1f9f2b73d60f57cc3568646929117825813
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Mostly unused #include's, also sort them or reduce scope.
A few namespaces, ...
Change-Id: I9ee71e07de7157c9942125672addf87dd41e78f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
clean, rename and delete unused constants, we well as unify the
usage between qmake, cmake, and qbs.
Change-Id: I8827ac2f2f7660e337694fef17f744e727bd776a
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Improve support for running iOS bundle built with CMake introduced in
3a294f670d.
Currently it supports only Xcode generator and does not work if target is
created in a subdirectory.
This patch adds support for non-Xcode generators (tested with Ninja) and
targets created in a subdirectories with any generators.
The solution is not pretty due to the need to keep qmake compatibility.
Would be glad to refactor if there's more correct approach.
Change-Id: Ieaf7e3186ab55cadc643d9bd3d94442f9ac72228
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Use buildSystem::property()/setProperty() to keep track of the
selected ABI and avoid polluting the *.pro file with it.
Task-number: QTCREATORBUG-24674
Change-Id: I5516a77c9f2d1a8975045e1d7c383e72c52db9d7
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Introduce bool QtSupport::supportsMultipleQtAbis().
Let AndroidQtVersion respond according to the QVersionNumber.
This allows to replace the version arithmetics in several
places with straight forward (and better findable) function calls.
Task-number: QTCREATORBUG-24471
Change-Id: Ib6e39fd6485a54e08ad66f84d4e2582989043419
Reviewed-by: hjk <hjk@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
(cherry picked from commit 430a33dcd9)
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Among others, this removes the wart introduced in 4d3d2d0dfb.
Change-Id: Iafa63f6e4cca327a1d1dd6a8bbcfaa10032327db
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The condition that's checked now triggered when playing around
with changing the JS expression that creating the default build
directory name.
Change-Id: I221be8cefb6918c10c383c23ee7cde73d3683e40
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
More a buildsystem than a node thing in general and removes
one use of activeBuildSystem and one use of the ProFileNode
-> ProFile back pointers.
Change-Id: Ie007fcd0db9e9294a08b3a1cd68f825c7d3dc9b8
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This will help collecting feedback from users affected by bugs.
Task-number: QTCREATORBUG-22508
Change-Id: Idfc22245587dd2d71b229b4ab6c7562fb7a5ecfc
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
No need for two manager type classes talking mostly to each other.
Change-Id: I82a52385df08dc4cddac2d294661341a79b86a4d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
If running 'Build File' and the 'objects_parallel_to_source' CONFIG
option is set for the project, make sure to modify the object file's
path so that it's target location is the relative to the build root
in the same way its source file's location is relative to the source
root.
- Add an accessor in QmakeProFileNode to check whether the
'objects_parallel_to_source' CONFIG option is set.
- Modify the object directory in QmakeMakeStep::init to ensure that it
has the same relative path to the object file from the build root,
as its source file has relative to the source root.
Fixes: QTCREATORBUG-18136
Change-Id: I63ef3af1fd4b7ef9fc46959f44d88b8025e99238
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Starting with Qt 5.14 we don't need "contains(ANDROID_TARGET_ARCH" scope
as we are doing multi abi builds in one go, therefore
contains(ANDROID_TARGET_ARCH,...) won't work anymore.
Fixes: QTBUG-79948
Change-Id: Icc989e4dfd48c765340569dcb547e8d0d2b1e8f1
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Effectively the same approach as for Android, but a bit more ugly
as we don't have necessarily access to the appman plugin headers
even at compile time.
Change-Id: I6d00e69b593470e059a16a1fcf6b57bdd550ae40
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... or Target.
This patch moves build system from conceptually "one per project"
to "one per target (i.e. per project-and-kit)" or "per
BuildConfigurations" for targets where the builds differ
significantly.
Building requires usually items from the kit (Qt version, compiler,
...) so a target-agnostic build is practically almost always wrong.
Moving the build system to the target also has the potential
to solve issues caused by switching targets while parsing, that
used Project::activeTarget() regularly, with potentially different
results before and after the switch.
This patch might create performance/size regressions when several
targets are set up per project as the build system implementation's
internal data are duplicated in this case.
The idea is to fix that by sharing per-project pieces again in
the project implementation once these problems occur.
Change-Id: I87f640ce418b93175b5029124eaa55f3b8721dca
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... instead of creating the BuildSystem direct. This will help the
shift of BuildSystem owner ship as a Project will have potentially
multiple BuildSystem instances (one per BuildConfiguration), but
still be responsible for creating them with the Targets.
Change-Id: I2dd71c7687ed41af9e42c874b3f932ce704e7ee3
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... and move context menu action handling there.
This is a temporary measure to be able to move that functionality
alongside the actual BuildSystem to the BuildConfiguration.
There is a lot to be cleaned up left, to keep the patch small.
Change-Id: If4b0820a13b376fc97b70785052924972ce22705
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This reverts commit d907df0349.
The original change was pushed to 4.10 and reverted there for
binary compatibility reasons. Revert the revert here.
Conflicts:
src/plugins/projectexplorer/projectnodes.h
Change-Id: Ibfd84a30a6cfdd78e1fa1b1c61785d391a5a18be
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Commit 81a643ec99, fixing QTCREATORBUG-22412, was too restrictive: UI
files in applications have access to resources of library dependencies,
so we must consider those. We now only exclude resources from other
applications.
Note that this will potentially list non-applicable resources, e.g.
those from libraries to which our product does not have access. This
cannot be reasonably prevented, because not all build systems provide
this information. It's also not as bad as missing resources.
Fixes: QTCREATORBUG-22909
Fixes: QTCREATORBUG-22962
Change-Id: I51a87402b43c156618982813c408060f300e4e58
Reviewed-by: hjk <hjk@qt.io>
... from a project which are pulled in via wildcards.
Such files cannot be removed from a project file, because they are
not listed verbatim. This kind of failure should not be reported to the
user if the file is also deleted, as the file list will have the correct
state after the next reparse.
Fixes: QTCREATORBUG-22586
Done-with: Christian Kandeler <christian.kandeler@qt.io>
Change-Id: I3dc66fe9a6594be7d0b86f46d830cd099ee49fd7
Reviewed-by: hjk <hjk@qt.io>
Duplication works for any file node whose parent project node can add
files. No need to duplicate (!) this logic everywhere.
This makes the "Duplicate File" action available for cmake, qbs, etc.
Change-Id: Id1f0378c3b3d7e2dbca4d6bbcca5df1c2d33ee0b
Reviewed-by: hjk <hjk@qt.io>
Provide general infrastrucure and implementation for qmake.
Fixes: QTCREATORBUG-16067
Change-Id: I8c6368fe2724c9450dcbc3410b6ca459bbbdc043
Reviewed-by: hjk <hjk@qt.io>
This lets users build the executable corresponding to the currently
active run configuration. It's functionally equivalent to locating the
corresponding node in the project tree and choosing "Build" from the
context menu.
Fixes: QTCREATORBUG-22403
Change-Id: Ic2b729c7ce17f1ad944dc06746bb9d6db90b6c61
Reviewed-by: hjk <hjk@qt.io>
More in line with QFileInfo terminonlogy which appears to be
best-of-breed within Qt.
Change-Id: I1d051ff1c8363ebd4ee56376451df45216c4c9ab
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
A product is a project node from which a target binary is produced, such
as a Product item in qbs or a .pro file in qmake.
Change-Id: I6a0e6bed6c02684cb03b2b18fed6a1b493fa78b2
Reviewed-by: hjk <hjk@qt.io>
Requirements:
- NDKr19 or newer
- Qt 5.12.1 or newer
QtCreator supports the following variables:
- ANDROID_PACKAGE_SOURCE_DIR
- ANDROID_EXTRA_LIBS
Be aware, that there is a lot of magic done on QtCreator side, and you
can't use only cmake to build an Android APK.
[ChangeLog][Android][CMake] Add Android support for CMake projects.
Change-Id: I1d351976ed56f424c2bc972f4ff7b5968147a2ed
Reviewed-by: hjk <hjk@qt.io>
