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>
This reverts commit ad729a4085.
This breaks non-test builds. namedSettings() is a non-static in Project.
Change-Id: I1675cddfd515a021482769d38092138dbaa055ee
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Even if the implementation allowed different lists than 'build'
and 'clean', that's the only set that has been used, ever.
If really needed, this could be re-instated, but for now having
them fixed removes part of the neeed for a two-phase construction
and helps to simplify user code.
Change-Id: I3df09a1829a7d020ef8963d358ea80f8d199ba13
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Currently diverting to the original Project::setRootProjectNode.
Idea is to focus on the BuildSystem <-> generated tree relation.
Change-Id: I8b20173e364713f0919cf4f8b76a2f79ef8770bb
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>
If you build without tests, you'll get an error.
Change-Id: Id4ce543da6f1a450f91c3f4fb2d862989339db7b
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
We use the same approach as for the generic project manager, namely the
QtCreatorDeployment.txt file.
Fixes: QTCREATORBUG-22965
Change-Id: Ia49dcd354b9ade8aeda259696aa29692cce1577b
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
Used for updating project parts, so move it near RawProjectPart.
Change-Id: I77aeffbdbfb3d2ec0de600f61dcf7fbb7a355a98
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@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>
This is used for parsing the project only, so reflect that in the name. Not all
projects have build configurations, so the old name did not make too much sense
for what this has been used for.
Eventually this code should move into the BuildSystem.
Change-Id: Iff766150b5fe370f2912b0b3b15348b1c1fad5b5
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>
Use setters/getters for the bool flags in
Project::needsBuildConfigurations() and
Project::hasMakeInstallEquivalent.
Change-Id: I5ce937c3a5e8e0db627cda02a9007f8c28ccda0c
Reviewed-by: hjk <hjk@qt.io>
A target can/should handle/use unparsed projects just fine.
Change-Id: I54b8399eab4b4fe7ead2de3cef8ab25cc7bbc621
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
For some reason, Q_UNUSED includes already a semicolon, adding one
on the user side creates an additional empty statement.
Change-Id: I9c5e8fac381345a60792cb75e2938fd53958d3b0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... from the environment.
Fixes: QTCREATORBUG-17985
Change-Id: I9b54e550121cfcc0684a6e173337d59d235c6107
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@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>
Qt 6 API will move away from it.
Use QVector for API and some std container for internal things.
Change-Id: Iff14d48a47d5ac52ade875d9c8c84ad8a4f577d8
Reviewed-by: hjk <hjk@qt.io>
Adds a cache entry "BUILD_PLUGIN_${NAME}", defaulting to ON which
can be set to OFF to disable building of a plugin.
Adds a extend_qtc_plugin function that should be used to add
properties to a plugin after add_qtc_plugin, instead of the
standard CMake functions target_... . The new function results
in a no-op if the plugin was disabled.
Change-Id: I57f6799620aea0aaa8b56acead4815ccced95911
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
The parsing code used to access all kinds of stuff (e.g. the project
tree and the toolchain manager) from the non-UI thread, which is not
allowed.
Fixes: QTCREATORBUG-22420
Change-Id: I4be47919d7e543376d31826dd380f66f4e060458
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
Based on Tobias Hunger's work from a few months ago.
The CMake configuration needs libclang and Qt paths specified as
CMAKE_PREFIX_PATH.
Auto tests are run with "ctest". At the moment the pass rate is 87%.
Change-Id: Iba98e39bf22077d52706dce6c85986be67a6eab0
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
