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>
Helps to cut down BuildConfigration::setInitializer() usage.
Plan is to have more of that where feasible.
Change-Id: I138fcffc743daaf7068b5236c2a19c9ca0e3e2d4
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The information is effectively derivable from kit and build type, so
do it only when needed.
Change-Id: Ideb4e5106a6a0632ade98aad894d5b7aa6f83126
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>
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>
... 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>
The CMake build types names are translated, which is fine in UI,
but we shouldn't use the translations in the directory name.
Debug/Release/RelMinSize/RelWithDebInfo are known in CMake world,
and don't cause any problems with MSVC when having translations
for Russian / Japanese.
Fixes: QTCREATORBUG-19984
Change-Id: Ia19326f0ca5d277b549f1b82bc569518f7b5c441
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
If the deployment configuration contains an "install into temp dir"
step, then the local file paths of the binaries built by the build tool
will not be in the list of deployable files, because all deployables
come from the temporary install dir. Therefore, look for just a file
name match as a fallback.
Fixes: QTCREATORBUG-21235
Change-Id: Ie3fad515515b4f28cc6bdef1254f4c05a0557569
Reviewed-by: Christian Stenger <christian.stenger@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>
... by a permanent connection, and only evaluate output for the
active build configuration.
Task-number: QTCREATORBUG-21235
Change-Id: I06f87f7ea680f8f25687a0c5ffc936c801ab7de0
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Add a class to abstract out the BuildSystem from the Project.
Thie idea is to make a Project have-a BuildSystem, so that
it can stop being one.
The Projects in the different ProjectManagers will get much
simpler that way (and many will only consist of a constructor
with some setter calls) and handles all the interactions
between the rest of Qt Creator and the project.
The complex code to interact with the build systems is then
separate from that.
Change-Id: I3bbb000bb1aed91f0b547ac493f743ede8afb8cd
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
And the default selected when configuring a project, since it was the
first.
Broke with 5dbfd46bcf which merged
"availableBuilds" and "availableSetups".
Change-Id: Ibc8c241595f3fee6f35e08fa83e499550eff869b
Reviewed-by: Tobias Hunger <tobias.hunger@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>
When the filesystem scan takes longer than the cmake parsing, then
resetData() was called on BuildDirManager by the CMakeBuildConfiguration
before the CMakeProject had requested its data.
Move some code back into CMakeProject to resolve this issue.
Change-Id: Ib21bdd63fdca79c2ad39a7e060df438b456700b4
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
There is no need to reset a reader when e.g. the build directory changes
when the server-mode reader is *not* used. So the one case where having
separate reparse-options for the case where the reader changes and the
case where it stays the same is bogus.
So unify the flags into one set and simplify the code accordingly.
Change-Id: I9bcfcc6333d574d49513ef1256a9a8597bda4ec7
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Add more logging of cmake parsing flags as cmake runs are requested
in the plugin.
Change-Id: I5231bd29dfeb6521218dc28c26a5b658ccb4059b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Move special CMake environment modification to CMakeBuildConfiguration.
Change-Id: I27f886db48d8c036f2f77f5ae8f239b405cb5721
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>
Just use the target name as buildkey. This is unique in cmake projects, so
there is no need to mangle the source directory into the whole thing.
This is a problem since different readers might report different source
directories. That will then result in RunConfigurations getting duplicated
after switching the reader types.
Task-number: QTCREATORBUG-22129
Change-Id: I849ab68f221d732341e98faa9a4e757d3a495b2a
Reviewed-by: hjk <hjk@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>
... by a non-mutating .stringAppended, doing the same.
Change-Id: I7adb6cae3415942cc9a80088bd75cda9d577d4a5
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
