The Gradle files are usually not modified by the user, so it makes
sense to make the default behavior not to copy them, unless explicitly
set by the user.
Change-Id: I67a5a8ea402def55a65a4e98588c57a598c5f7d0
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Keep the old method for now to ease downstream porting.
The change is kept mechanical, there's a lot of cleanup possible now
on the user code side.
Change-Id: I936baedd45b7ba057f1c789a1bec896886f48eff
Reviewed-by: André Hartmann <aha_1980@gmx.de>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Instead of a Target and hoping that its activeBuildystem is the
right one.
Change-Id: Ieb384d89e8f580b24205ce46a38f151aa72e2f6e
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Qt 6 will not use qmake to identify a Qt version, so this can not
be part of the public interface of BaseQtVersion anymore.
Provide getters for the information actually read via qmakeProperty(...).
Use the getters whenever possible.
Change-Id: Iadbee80b75e4f8b06caf90e7ed69fae2029b4dd7
Reviewed-by: hjk <hjk@qt.io>
Previously, AndroidManager::updateGradleProperties operated always
on a project node found using target->activeRunConfiguration()
which might or might not be the one that will actually be used
after the build.
This here still does not address the problem that the activeRunConfiguration
may change but introduces a way to specify the relevant node, and tries
to use the right one when available.
At some time, this could be developed into a real solution, e.g.
by invalidating the cache on build key changes.
Change-Id: I37a3d73e9ad3615025e4def2493f683d11add3c6
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
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>
Mainly to get rid of the QProcess::finished deprecation warning.
Also adjust coding style in the surrounding connects when needed.
Change-Id: I12f9b248c7974b892c4a069356e578e80f8c59e9
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
A convenience wrapper for
applicationTargets().buildTargetInfo(buildKey),
the only context using the BuildTargetInfoList member.
Also, only one of the free comparison functions is ever used,
only in one place. Inline it there.
Change-Id: I7565e9d51d429af34352649e235243e5b3328fe9
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The name "KitInformation" does not properly convey the fact that it
represents a certain *aspect* of a kit. The same goes for
"KitConfigWidget", which in addition was inconsistent with
"KitInformation".
We now use "KitAspect" and "KitAspectWidget".
Change-Id: I9804ee4cedc4d61fad533ea1dd4e4720e67fde97
Reviewed-by: hjk <hjk@qt.io>
... from ProjectNode::targetData and setTargetData, and rename them
to data and setData.
It was only used in the implementation to retrieve the right node,
instead move the responsibility to find the right node to the caller.
Current assumption is that the functions were always called on
the right node already.
Change-Id: I9ae7e8a7ed5c79b924b99fd9a6a652bad56d114a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This uses the same approach as in the previous patches: Have some
generic interface in the base classes (here ProjectNode::targetData()
setTargetData()) and implement on the qmake project side.
Implementation for Cmake/QBS is architecture-wise possible, but
not used right now, and left for later.
Change-Id: I3bbf66170020cf9027a894cd66db15ec7ffbf499
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This makes it more similar to the classic QAbstractItemModel::{data/setData}
pattern and hides qmake-specific semantic (variables are QString*Lists*)
behind something more general.
Change-Id: I82d7006affd4af208be2b7640076698d13fd3a61
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
- Split up androiddeployqt into two steps: One building the apk,
and one deploying it to the device.
- The build apk step base class AndroidBuildApkStep is ihneritaged by
the qmake specific class QmakeAndroidBuildApkStep.
- The deployment step is still called androiddeployqt
- Move all qmake specific code to the qmakeprojectmanager plguin
- Flip the depencency between the android and qmake plugin, now
the qmake plugin depends on the android plugin, implementing
a interface the android plugin provides.
- Note: This removes the debug deployment for now.
Change-Id: I1c386640159ed14b637668abde8eb3b9009ab803
Reviewed-by: BogDan Vatra <bogdan@kde.org>
There are multiple copies of these pngs in different plugins.
Let's have one version in core, also as @2x variant.
Change-Id: Iedff1a6190a72c1947dd202ae1ee46f59f9fb13c
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Reviewed-by: Alessandro Portale <alessandro.portale@digia.com>
Instead of repeating strings like
":/projectexplorer/images/compile_warning.png" all over the code,
we should use constants for it.
Change-Id: I91b36838d6da0a2332381e433788e796948d26db
Reviewed-by: hjk <hjk121@nokiamail.com>
The workflow for adding a library for multiple archs is not ideal, but
now a little better. The user has to go to the deploy setting for a
kit per architecture and add the right extra library.
Change-Id: I2bda6961f6f1164bdc58acd78fa3d2221977f0cf
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
On creating a AndroidManifest.xml we ask the user where to put the file,
which as a sideeffect also sets ANDROID_PACKAGE_DIR.
Since we copy everthing from ANDROID_PACKAGE_SOURCE_DIR into the build
directory, using the project's source directory is not desireable.
We now show a big error if the user tries that.
Task-number: QTCREATORBUG-11708
Change-Id: I7fade3efac0b7466cad8e83a92c2115d0a70c683
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
QTBUG-28385 is biting us over and over (QWizard doesn't have close
button nor cancel button on Mac in Qt 5), and actually there's no reason
for us having a wizard without the features from Utils::Wizard.
Task-number: QTCREATORBUG-10346
Task-number: QTBUG-28385
Change-Id: I80c0d82fe6738496c2ac03c31a1c2757ade8e266
Reviewed-by: Jarek Kobus <jaroslaw.kobus@digia.com>
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
The AndroidManifest.xml is no longer needed in as many use cases as
before. So the new deployment does not automatically create a
android manifest. Offer a button on the deployment page to create
a android manifest. This also edits the .pro file adding the
ANDROID_PACKAGE_SOURCE_DIR.
Change-Id: I2655dd6c96e2087732b4d7240b31fe9fcf168600
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
