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>
For Compile, BuildSystem and Deployment. Unclutters user code and reduces
binary size.
Change-Id: Ia18e917bb411754162e9f4ec6056d752a020bb50
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>
Allows to use constants in fewer places, similar to what e.g.
RunConfiguration does.
Change-Id: I9d049128206c4acf0ce14b06b66d6c090a7c5242
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 projectexplorer.cpp file is a huge mixed bag, which could use some
cleaning up. The queue() function is very much related to the
BuildManager, so move it there.
Change-Id: Ibc6425cc27d44514803a5e7c6139f83ddd760382
Reviewed-by: hjk <hjk@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>
... instead of the entire project.
This can speed up the development cycle by ignoring irrelevant changes
in the project, potentially at the cost of missing parts that actually
should be re-built (in particular with build systems where a product
does not have full knowledge of its dependencies).
Supported by qmake and qbs for now.
Change-Id: Ic7101aa243e92ba139798d13366d256c1919dcc3
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
... when initializing build configuration.
Potential re-alignment with contents of pre-existing Makefiles
is confusing at best, and depends on the presence of Makefiles
that are typically close to invisble when using an IDE.
Change-Id: Iadbab4f32badfbf948cfa2a1b256932acbfe858f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
In line with the general move toward use of FilePath nowadays.
Change-Id: I1c50e1479f7d9100ff8ded3ce3c22dd82b7fe6aa
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Allows more compact code on the user side in most cases and
can hide the internal 'int-ness' from user code by wrapping
Variant conversions in the TriState class itself.
Change-Id: I4c91e0cd798ee988a0b9cb057749251a4efebaff
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>
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>
Looks like the information has been based derived from
buildDirectory() != target()->project()->projectDirectory()
for a while.
Change-Id: Ieb64e72d8fd1d4a6a339b695422fff6355cd3969
Reviewed-by: Christian Kandeler <christian.kandeler@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>
... to the config widget implementation, which is the only user.
Change-Id: I7cc70b6219dacedf1ef431a1fe21345b9ad69e7b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... by direct emission of the signal. Signals are public nowadays, so
the indirection is not needed anymore.
Change-Id: I82328a8fa05458e0478a52157863b7265f0a42ad
Reviewed-by: Christian Kandeler <christian.kandeler@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>
... and BaseQtVersion, and QmakeBuildConfiguration.
Change-Id: Iac5f768b80a7f8c2ea9a37d099b285d5793270db
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
While configuring a project, a wrong warning "Warning: The build
directory should be at the same level as the source directory." was
shown in some cases.
The reason was the innocent assumption that "projectPath" was just the
directory part of the project root. It was in fact the full "file path"
of the .pro file.
Change-Id: Icc5df51423b4bb05098d9d42cd328af949f85005
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The infamous "build dir is not at the same level at source dir" warning
for qmake projects has gone through a number of iterations in Qt
Creator, having been added, removed and re-added, always to the
criticism of some users. Our new approach is as follows:
- The warning appears at the widgets where the build directory is
set, both in the target setup page and the build config widget.
- The warning also appears in the issues pane, but only if the build
failed.
- The user can disable the warning altogether in a newly introduced
qmake settings page.
- This option is disabled by default on Unix, because to my
knowledge all failure reports have been for Windows hosts.
This should finally please everybody.
Fixes: QTCREATORBUG-16945
Change-Id: I638be1f15e8c260a5d72047d6850a3a0f685cf03
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The name "KitInformation" does not properly convey the fact that it
represents a certain *aspect* of a kit. The same goes for
"KitConfigWidget", which in addition was inconsistent with
"KitInformation".
We now use "KitAspect" and "KitAspectWidget".
Change-Id: I9804ee4cedc4d61fad533ea1dd4e4720e67fde97
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>
The remaining dependency is hacked into QmakeProjectManager
by using a compile time-only dependency on androidconstants.h.
Change-Id: Id78125137bc75c145a072bc753276abbf0029647
Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io>
These are not used during parsing but when operating on the items
in the project tree.
This loosens the ties between the qmake related parser and project
nodes.
Change-Id: I077356fcde240df56b466c71c902c821c4885f6d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
That's effectively a generic hook for "re-run qmake" without the
qmake/QmakeProjectManager dependency.
Change-Id: I236d40690cde9047831422b2651ed2284b220959
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
When building a sub-project using the context menu -> Build, qmake was
executed every time, because the pro file in the Makefile was compared
against the root project instead of the sub-project.
Change-Id: Id76d7d23e3fa9a8e4c5c10cd10adcc945ff3b186
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
If the user used a macro, the Makefile will never match it, and qmake will
be executed on each build.
Change-Id: I2790db3a788ea7971145b475781a6193a1ed0842
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
