Adds the signing settings to iOS configurations.
Adds placeholders for signing flags to the initial CMake arguments, and
updates the CMake configuration when signing settings change.
The new configuration doesn't get automatically applied. Only the "Apply
Configuration Changes" button gets enabled and the user has to press
that explicitly. This seems to be a more general issue affecting the QML
debugging setting too, though.
Task-number: QTCREATORBUG-23574
Change-Id: I3e8d45f565347e1ad2ac274a21b1552f1510e8f4
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
CMake has multi-config generators like:
* Visual Studio
* Xcode
* Ninja Multi-Config
The first two have different special targets for "all", "install",
"package", "test" namely: "ALL_BUILD", "INSTALL", "PACKAGE",
"RUN_TESTS".
All of them need to get the build type passed via "--config <build-
type>" and not via "CMAKE_BUILD_TYPE".
The multi-config generators will use only one build directory.
Fixes: QTCREATORBUG-24984
Change-Id: I8aa7ff73ce2af1e163b21a6504d26fcf95530edf
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The CMakeCache.txt file has CMAKE_HOME_DIRECTORY pointing to the
project source directory used to configure the project.
When importing a cmake build the CMAKE_HOME_DIRECTORY from
CMakeCache.txt might not point to the same CMakeLists.txt that was
opened as a project.
qt-cmake-standalone-test from Qt6 uses a CMake template project which
does a add_subdirectory with the test source directory, which will not
work if opened standalone.
Normally this is a user error though, so ask the user if this was
intended, before actually importing the build.
Task-number: QTBUG-88776
Change-Id: Ifdd5e1d1cb8a1ef9955d22493eba3a1a55dc689f
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The latest libClang gives us following warning:
cmakebuildconfiguration.h:104:18: warning: unqualified friend
declaration referring to type outside of the nearest enclosing namespace
is a Microsoft extension; add a nested name specifier
Deleting is the right fix.
Change-Id: I4ccccf286044ca45ec78b0ea03a4ce8d979f06b4
Reviewed-by: hjk <hjk@qt.io>
Classes involved are BaseAspect and some derived classes,
LayoutBuilder and VariableChooser.
This is mostly mechanical, with various include/using changes
to make it compile.
Change-Id: I624a457f3555f102e541c4c71e33a9423af32250
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
In most cases they are used directly, so there's not much Base* in that.
Added the old name as alias as porting help for a while.
Change-Id: I494a8a560b8996bcf74915ea3570b504df6a6b4c
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Get rid of magic configuration handling in the CMakeProjectManager.
* Use CMakeCache.txt as the sole source of truth, do not keep
a shadow copy of configuration in the .user file
* Have initial CMake arguments that are easy to edit in batch
(Fixes: QTCREATORBUG-18179) used whenever no CMakeCache.txt
file is in the build directory. These allow for any thing that
can be passed to CMake on the command line.
(Fixes: QTCREATORBUG-16296)
* Ask when changes to CMake configuration were not applied
(Fixes: QTCREATORBUG-18504)
* Run cmake with arguments effecting its configuration only when
the CMake settings are changed in the UI, run CMake without any
special arguments in all other cases.
* Get rid of the confusing dialog used to keep settings in sync between
what is in CMakeCache.txt and Creator (Fixes: QTCREATORBUG-23218)
Change-Id: I26d55be7df733f084f5691ecf7d7b4352f58b8e7
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The BuildDirManager was used to switch between different
BuildDirReaders. Now that only the FileApiReader is left, that
infrastructure is no longer needed.
Change-Id: I2d339a3407bb633cff6a8f7502b7b09094f63fef
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Keep internals internal, remove some unnecessary includes, add
some that should have been there.
This reduces the number of files that get rebuild when working
on CMake internals from over 1000 to about 200.
This patch also moves some code around that ended up being
in the wrong file.
Change-Id: Icd7366ac760dc85031040720418fbb16336dce9b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
I can't spell occurred:-/
Similar typos in 3rd party code (sqlite) has been left in place.
Change-Id: I7cfa9911fc434d42ce3df8e9c7ccb83dc00401e8
Reviewed-by: hjk <hjk@qt.io>
There should not be a need to have the linkQmlDebuggingLibrary Q_PROPERTY
anymore. The property is added for the benefit of the DebuggerAspect, which
can just check relevant BuildConfigurationAspect directly.
Change-Id: Ic47ca9e26911e096564fe77bd14bebe959b4f116
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The current implementation does not help the user and is not in sync with isEnabled(),
so it is not helpful to have.
Change-Id: Iddde1ac3da24d50e8a16d2bd4c6aa56eef34ef50
Reviewed-by: hjk <hjk@qt.io>
Add a respective aspect to the build configuration
for handling qml debugging from the build side
similar to what we do with qmake and qbs.
Qml debugging needs to get enabled on the build side
before the settings on the run configuration page
has an effect.
Fixes: QTCREATORBUG-23541
Change-Id: I86267747601015760737d8b21978712896892a37
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The QObject was not heavily used. Object name was for debugging only,
translation context can be taken from the corresponding BuildConfiguration
objects, the qobject_casts in the three big importers are replaced by
dynamic_cast, which is good enough in that context.
Take the opportunity to re-use translations from base BuildConfiguration
for the common cases and sprinkle in some 'final'.
Change-Id: I8e9727c98c6e943cb333556861c24e701c2bdf45
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The base version is good enough nowadays.
Change-Id: I2e2ca690a29f9b877309ca98038d211d5c678fbd
Reviewed-by: Christian Kandeler <christian.kandeler@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>
Doesn't have any dependencies into CppTools anymore, therefore moving it
reduces the dependencies of the project managers to CppTools as well.
Change-Id: Ibe728abe59eb88a8877943dca1f48a85163e27ac
Reviewed-by: hjk <hjk@qt.io>
For now, store most of BuildInfo in the BuildConfiguration. This will
allow accessing it in the BuildStep ctors so the BuildSteps can
be fully setup without polishing afterwards (as currently done
in the main build steps of the three buildsystems, and Nim)
This in meant to be temporary to a large degree.
Change-Id: If6ade6052f4b96670995399ae97ef7d2313f632a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Make all buildconfigurations disabled while the project parses.
This unifies how this is handled in different build systems.
Change-Id: I6afca3743ad1433529a4f9d3bfdf73042799e456
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Introduce BuildSystem to implement functionality common to all
build systems out there. This includes things like delaying the
parsing by 1s.
The actual CMake specific code is then moved into a derived
class CMakeBuildSystem.
Change-Id: I84f4344430f19a44e16534db294382c436169ed5
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Move code closer to the BuildDirManager that was moved into the
CMakeBuildConfiguration.
Change-Id: I21d7188e4a3b03a02b12b01c7dd3e46754d653f8
Reviewed-by: hjk <hjk@qt.io>
... and availableSetups as far as mechanically possible.
Change-Id: Ia1d7babe943eea25da97cef7838187c234378673
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... availableBuilds() and availableSetups().
Goal is to merge them and inline all the local createBuildInfo()
functions.
Change-Id: I9f19093163808b6da6dc83977894420e08a1edd9
Reviewed-by: Christian Kandeler <christian.kandeler@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>
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>
... to pass it around as real values, avoiding, among others,
the need of occasional explicit deletion.
The formerly extra members of the derived stuff are handled via
an extra variant (for data) and via a functor in the build
configuration factory.
The change is mechanical.
Change-Id: I19ca4e0c5f0a5b196fc16dfb98bb005dc679f855
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... to BuildConfigurationFactory. It hasn't been an Interface for a
while and the new name matches Run- and DeployConfigurationFactory
Change-Id: I923c6a27e18a99628251b69e0270e910836e7b2a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Less use of activeBuildConfiguration and activeTarget.
Change-Id: I9fa77a0084c5701e86530e4f9845c47baddaed4e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
It's what the base class wants, and follows run and deploy precedence.
Change-Id: I26eff43337851702417e7e4284fc390b904060f6
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This follow the rough pattern of recent *RunConfigurationFactory changes
for build and deploy configurations.
- Collapse the two lines of constructors similar to what
890c1906e6 did for RunConfigurations
* Deploy* was purely mechanical
* Build* ctors are split in connects() in the ctor body
to create "empty shell for clone" etc
and build step additions in initialize() functions which
are only used in the create() case.
-- Allows to collapse the shared 'ctor()' functions, too.
- Move FooBuildConfigurationFactory::create() implementations
to FooBuildConfiguration() constructor. That was a strange
and unneeded ping-pong between factories and objects, and
furthermore allows one level less of indirection (and for a
later, left out here, some reduction of the
FooBuildConfiguration interfaces that were only used to
accommodate the *Factory::create() functions.
- Most {Build,Deploy}Configuration{,Factory} classes had a canHandle(),
but there wasn't one in the base classses. Have one there.
- Most canHandle() functions were checking simple restrictions on
e.g. project or target types, specify those by setters in the
constructors instead and check them in the base canHandle()
- clone() is generally replaced by a creation of a "shell object"
and a fromMap(source->toMap()), implemented in the base, there
are two cases left for Android and Qbs that needed(?) some extra
polish
- generally use canHandle() in base implementation, instead
of doing that in all Derived::canFoo()
- as a result, canCreate/create/canClone/clone reimplementations
are not needed anymore, keep the base implementation for
now (could be inlined into their only users later), but
de-virtualize them.
- Combine Ios{Preset,DSym}BuildStepFactory. There was only one
'dsym' build step they could create.
- Split the 'mangled' id into the ProjectConfiguration subtype
specific constant identifier, and a QString extraId() bit.
Only maintain the mangled id in saved settings.
- Make ProjectConfiguration::m_id a constant member, adapt
all constructors of derived classe.
Not done in this patch:
- Finish possible cosmetic changes on top
- Add a way to specify restrictions to supported Qt versions
(used in Android/Ios), as the base implementation does not
depend on the qtsupport plugin
- Combine the QList<X> availableFoo() + createFoo(X) function
pairs to somthing like a direct
QList<struct { X; std::function<X()>; }> fooCreators()
to avoid e.g. the baseId.withSuffix() <-> id.suffixAfter(base)
pingpong
- Remove the *Factories from the global object pool
- Do something about priority(). Falling back to plain
qmake in android+qmake setup is not helpful.
Change-Id: I2be7d88d554c5aa8b7db8edf5b93278e1ae0112a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
It confuses lupdate (QTBUG-36589), and is totally unrelevant in this
case.
Change-Id: I65444fcdb62b7d95de9f22025272508aa3bf272e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This builds on top of 08677c0b01 and
fixes one more code path to go through a common entry/exit point.
Change-Id: I1d00fa9242f247028e5d3b0ef3b5fe1d3f4cb03d
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
The directory tree scanner and the project parsing work independently of
each other. Add logic to combine these two sets of results into one
parsing state.
Change-Id: I46e94f0e866b40ee7225235c536c742cecf11b45
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Do not update the existing project tree anymore: Start a fresh one
and throw the old one away.
Change-Id: Ifabe293b6ca668b0672516a6d81acd5346d98fe5
Reviewed-by: hjk <hjk@qt.io>
Make sure the buildconfiguration is disabled while parsing and that
it becomes enabled again after an error in CMake is fixed.
Change-Id: Iec919e3c74c465a14ebb87adb9af142537823f00
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
${AnyProject}::updateCppCodeModel() did two potentially not that cheap
operations in the ui thread:
(1) Querying the MimeDatabase for the mime type for the source files of
the project. In 99.9% of the cases no files need to be read for
this as the file extension will resolve the type. The expensiveness
comes from the sheer number of files that can occur.
(2) Calling compilers with the "(sub)project's compiler command line"
to determine the macros. While the caches avoid redundant calls,
the number of the unique compiler calls makes this still a
ui-freezing experience.
These two operations are moved into a worker thread. For this, the
expensive compiler calls are encapsulated in thread safe lambdas
("runners") in order to keep the "mutexed" data minimal. The original
API calls of the toolchains are implemented in terms of the runners.
While adapting the project managers, remove also the calls to
setProjectLanguage(). These are redundant because all of the project
managers already set a proper value in the constructor. Also, currently
there is no need (client) to report back detection of C sources in
project parts. This also keeps CppProjectUpdater simple.
There is still room for improvement:
* Run the compiler calls in parallel instead of sequence.
* Ensure that the mime type for a file is determined exactly once.
Change-Id: I2efc4e132ee88e3c8f264012ec8fafe3d86c404f
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
