The hidden extra target creates all kinds of inconsistencies, e.g.
between mini project target selector and target model.
Besides, there is no reason why this project manager should behave
differently from the others in this respect.
Fixes: QTCREATORBUG-23518
Change-Id: I11022f63bed33191f6349681356b4dd9537de50c
Reviewed-by: hjk <hjk@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>
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>
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>
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>
A target can/should handle/use unparsed projects just fine.
Change-Id: I54b8399eab4b4fe7ead2de3cef8ab25cc7bbc621
Reviewed-by: Christian Kandeler <christian.kandeler@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>
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>
Files listed in an optional "compile_database.json.files" are also
visible in the project, similar to the GenericProjectManager.
Change-Id: I1250b674298079bab90a0ffe036107a09b4ac6e5
Reviewed-by: Thomas Otto <totto@zbh.uni-hamburg.de>
Reviewed-by: hjk <hjk@qt.io>
If the sysroot option is found - set it as a kit sysroot (only
in CompilationDatabase project where we have a cloned kit
which does not affect the other existing kits).
In other cases use the backup for the sysroot from the
toolchain (can exist for clang toolchains based on mingw).
Provide target when searching builtin include paths for clang.
Fixes: QTCREATORBUG-22339
Change-Id: Ibe07c2e490ba4f7e0d259e6df698d641dbfd0298
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The 'directory' field of a compilation database can be
in many cases another root directory to look into.
Change-Id: Ie0d11bdc706f09e4d466b20fef614dd6ce00d4e9
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
In addition export the ProcessStep class from ProjectExplorer
not to duplicate the code.
Task-number: QTCREATORBUG-21727
Change-Id: I43d0c83b0338995fdb37ace940092c83ce2b6820
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
- do not convert the DOS path if it does not exist
- pass the proper flags to addDriverModeFlagIfNeeded
- reset the kit toolchain before picking the matching one
- do not show the popup when running plugin tests
- clang++ contains 'g++' but it's not a gcc compiler
Change-Id: Ia5018a2131bb123202b87e34e0ac3a79f0feb45d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Most of the flags in compilation database are the same,
let's share them by inserting them all into the temporary
QSet of QString-s.
Change-Id: I7d9b410b4b0bee40247434b49371bd37214d4c59
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Let's use the same approach we have for CMake projects by using
the same TreeScanner class.
Compilation database does not have a concept of the root directory
so let's show a file dialog and ask for it the first time the project
is loaded. Next times we open it we take this path from settings.
This root path can later be changed from the project tree context menu.
Fixes: QTCREATORBUG-22031
Change-Id: I151aed8d0504b2e8aa14aa774cad25f8c86d5c17
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reparse the compile_commands.json file when it has changed.
Fixes: QTCREATORBUG-21733
Change-Id: I8e5a99efd136b1d46a417817bde5b5b989109eea
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
Not much protection needed, and not provided either, as seen in
the removed workarounds.
Change-Id: Ib33f6481cdb04481c0324bdeb57eb50143ecb62f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
