Previously every time a qmake project was built, the
"buildDirectoryChanged()" was emitted, leading to a complete
reparse of the project file, tests, qml files and qml imports.
To keep "QmakeBuildConfiguration::updateProblemLabel" be called,
we re-introduce the "buildDirectoryInitialized" signal.
Task-number: QTCREATORBUG-27785
Change-Id: I32d881eacb8cf26050c33da643c74c2cab4dc22d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Task-number: QTBUG-67283
Change-Id: I708fd1f9f2b73d60f57cc3568646929117825813
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... for use in the default build dir template.
Task-number: QTCREATORBUG-26147
Change-Id: I1a32d60e0d5e2db514ac315c48c615c55ccda51f
Reviewed-by: hjk <hjk@qt.io>
There's only one kind of use, in the context of BuildConfiguration.
Change-Id: I09628ff443ef08e28738125a614c17d5d979189b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
When working with make wrapper scripts, sometimes they forward
everything to stdout. When this happens failures are not parsed,
and the are not "clickable" in QtC.
This patch adds an option to enable parsing of standard output.
Change-Id: I44b283dbdf6286f90c546898d496bff41de0d5ed
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Once we parsed the project initially, subsequent parses typically do not
change things in a major way, so we can expect e.g. run configurations to
stay intact.
It therefore makes sense to allow users to schedule an
application run not only during a build (see 4b92b7ac60), but also
during a parse. Arguably, this is even more relevant, as parsing is
usually not triggered directly by the user, but happens as a side effect
of editing a document or switching a branch. It is then annoying for
users to have to wait until the respective buttons get enabled again.
Fixes: QTCREATORBUG-24986
Change-Id: I1081ccde668eee794c39b96cd0bad5c3aaa580bc
Reviewed-by: hjk <hjk@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
They can now be created independently of any toolchains, and we expose
them in the build and run configurations, so that users can easily get
tasks for output that comes from custom tools or is otherwise specific
to the user's environment.
Fixes: QTCREATORBUG-23993
Change-Id: I405753b9b68508ffe5deb4fcac08d6b213c7554d
Reviewed-by: André Hartmann <aha_1980@gmx.de>
Reviewed-by: hjk <hjk@qt.io>
Use the helper in CMake. Everything else does not seem to directly
create directories.
Change-Id: I50fba8c461471a1bcd0f9c187a857730c35e4f8f
Reviewed-by: hjk <hjk@qt.io>
It's never used polymorphically, and only caused an unused
implementation in BuildStep.
Change-Id: I5fbd34925788ca22960a2f522eef75be3137c67b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... by MacroExpanders in Build and RunConfiguration. Deploy didn't
use its own, BuildStep always composed an empty expander with
the BuildConfiguration's, uses now the BuildConfiguration's expander
directly.
Change-Id: I9de51bfc32aeb3d73f4974175e42a37807e49ac1
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>
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>
... 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>
It's quite fat already and will own the BuildSystem later.
Change-Id: I5b9edd27fbd485b4e2b74cd9c57084d2874089bb
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>
... with a suitable default implementation accessing a member
populated at construction time instead of walking the parent
chains on each access.
Change-Id: I58dae6da80ed0b023cc603fca13a5a205b123672
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>
Refactor much of the code from Environment* classes to NameValue* classes
to share it with the preprocessor macro settings.
Change-Id: Ica4ee817aa338230c422b30d91240d266248d226
Reviewed-by: Tim Jenssen <tim.jenssen@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>
This is getting repetitive.
There's a new connect too, that's not wrong in the current two uses
and will be helpful in the upcoming Qbs one.
Change-Id: I4a4923a43937922c66be1f73822103b1e3e7b077
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Just for the "storage" part with this change. Plan is to also
use the gui parts one-by-one in the BuildConfig reimplementations.
Change-Id: Ie5e4e701eea8d83336103654c708f4f1ab8132e8
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Mimicking the other aspect-unsing setups. It is currently re-implemented
in all derived classes, i.e. unused.
Change-Id: Ia1c16318347baa13a869d3eb03717a0f5ff0d8f8
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It's essentially an intrusive hack that's used only to prioritize
Ios+Qmake over plain Qmake. The effect is now achieved by an
arguably equally evil dependency on the construction order of
BuildConfiguration factories.
It can be argued, however, that this is a feature as it allows
user plugins to intentionally override core functionality by
using the standard setup pattern and depending on the to-be-
overridden plugin.
Change-Id: Ic1efa305daf3ca19a880d2a7ccb40e2768d8f57c
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... also for BuildConfigurationFactory, similar to Run and Deploy.
Change-Id: I453f08bf145d6a2e764d150646c698d624ae2ce9
Reviewed-by: Eike Ziller <eike.ziller@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>
Instead of qobject_cast use the reacently introduced virtual function
BuildConfiguration::regenerateBuildFiles() to trigger the necessary
work in the qmake case.
Change-Id: Ie5fd36550b5bad8c5f3f8bb1e2a3a16843f8f5b7
Reviewed-by: Vikas Pachdha <vikas.pachdha@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>
It's what the base class wants, and follows run and deploy precedence.
Change-Id: I26eff43337851702417e7e4284fc390b904060f6
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Following the RunConfigurationFactory lead this replaces
f = Foo::find(); f->do() by static Foo::do() stanzas.
Also de-virtualize/private-ize IBuildConfigurationFactory::canCreate()
as it is only a local helper nowadays.
Change-Id: Id36ba514f426ebd054592189aa29c170ba00d92f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
