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>
Add helpers to deal with CMakeBuildTypes and to map them to
BuildConfiguration::BuildTypes.
Change-Id: I03ce9e83b5d044c3d94d29c44cc0a28560b206f6
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
This makes sure they need to copy whatever they need.
Change-Id: I767ac0c5f54ca1f9f46acdefe4bd7fea35657312
Reviewed-by: Alexander Drozdov <adrozdoff@gmail.com>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Project source tree is a same for all build configurations so it is
a good idea to keep it persistent between CMake runs, configurations
switches and so on. It safes a lot of time for big projects.
Move more operations to the scanner thread:
- Nodes filtering: skip .user files on top level of the project, skip
well-known extensions and octet-streams: In most cases these are not
required to be shown in the project tree.
- Nodes sorting
Fix small memory leak: we have .user in the scanner result. After this
node filtered out, but is not feed (old code at the
BuildDirManager::generateProjectTree()). Now .user file skips during scan
without memory allocation at all.
Allow user manually rescan project tree by call Build -> Rescan project
tree. It runs CMake and Tree Scanner together: in most cases only CMake
run requires but time to time (VCS update) full rescan also required.
Change-Id: I4a6e6c897202da557509291c79932dd7751860e5
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This fixes saves memory and fixes some update issues with the cmake
configuration, where the three layers of caches used to interfere
with each other.
Task-number: QTCREATORBUG-17360
Change-Id: I5564bbe46ca8de6b38dd710100bfc18fad98eac5
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Only the original one is implemented so far, but at least
in theory backends for retrieving data from cmake can now
be switched at runtime.
Change-Id: Id73a81c7d40f078be95defd30a38511dca3a3720
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Continue to concentrate all the code reading random cmake files in
BuildDirManager. Now the task is to clean up the code, make it less
dependent on values it should not depend on (kits, etc.), make it
handle changes better and finally add another implementation that
uses the cmake server mode to extract the data.
Change-Id: I533625e376b969b64287bc205bd2e4be7a605306
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
