... 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>
There are two differences that get introduced by this change:
- The configuration widget checks that there is a build configuration,
but not if this build configuration is a QmakeBuildConfiguration. This
should not matter, since Qmake is still the only supported project
type for the qmake specific make step
- It removes the automaticallyAddedArguments(). As far as I can see this
never had any effect anyhow, though. They were never actually added to
the arguments.
Change-Id: I73be227a32117e462def38bdd040dbd7cbcc113f
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>
This follow the rough pattern of recent *RunConfigurationFactory changes
for build and deploy configurations.
- Collapse the two lines of constructors similar to what
890c1906e6 did for RunConfigurations
* Deploy* was purely mechanical
* Build* ctors are split in connects() in the ctor body
to create "empty shell for clone" etc
and build step additions in initialize() functions which
are only used in the create() case.
-- Allows to collapse the shared 'ctor()' functions, too.
- Move FooBuildConfigurationFactory::create() implementations
to FooBuildConfiguration() constructor. That was a strange
and unneeded ping-pong between factories and objects, and
furthermore allows one level less of indirection (and for a
later, left out here, some reduction of the
FooBuildConfiguration interfaces that were only used to
accommodate the *Factory::create() functions.
- Most {Build,Deploy}Configuration{,Factory} classes had a canHandle(),
but there wasn't one in the base classses. Have one there.
- Most canHandle() functions were checking simple restrictions on
e.g. project or target types, specify those by setters in the
constructors instead and check them in the base canHandle()
- clone() is generally replaced by a creation of a "shell object"
and a fromMap(source->toMap()), implemented in the base, there
are two cases left for Android and Qbs that needed(?) some extra
polish
- generally use canHandle() in base implementation, instead
of doing that in all Derived::canFoo()
- as a result, canCreate/create/canClone/clone reimplementations
are not needed anymore, keep the base implementation for
now (could be inlined into their only users later), but
de-virtualize them.
- Combine Ios{Preset,DSym}BuildStepFactory. There was only one
'dsym' build step they could create.
- Split the 'mangled' id into the ProjectConfiguration subtype
specific constant identifier, and a QString extraId() bit.
Only maintain the mangled id in saved settings.
- Make ProjectConfiguration::m_id a constant member, adapt
all constructors of derived classe.
Not done in this patch:
- Finish possible cosmetic changes on top
- Add a way to specify restrictions to supported Qt versions
(used in Android/Ios), as the base implementation does not
depend on the qtsupport plugin
- Combine the QList<X> availableFoo() + createFoo(X) function
pairs to somthing like a direct
QList<struct { X; std::function<X()>; }> fooCreators()
to avoid e.g. the baseId.withSuffix() <-> id.suffixAfter(base)
pingpong
- Remove the *Factories from the global object pool
- Do something about priority(). Falling back to plain
qmake in android+qmake setup is not helpful.
Change-Id: I2be7d88d554c5aa8b7db8edf5b93278e1ae0112a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Set up a better environment for initial project parsing (before Kits
are configured).
Task-number: QTCREATORBUG-19241
Change-Id: I2431113dbbe6fb6a66f95fb1efb36834fa184f3d
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Do not unconditionally prepend QT_HOST_BINS to PATH as part of the Kit
setup.
Prepend this directory to PATH in the Qmake- and GenericBuildConfigurations
instead.
Task-number: QTCREATORBUG-18714
Change-Id: I1c1d1362105b82f9c369d989e90d4f7079c2c9a2
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Do not unconditionally prepend the (c++) compiler path to PATH for
all projects using GCC-derived toolchains.
Prepend the compiler path in the Qmake- and GenericBuildConfigurations
instead.
Also change the order: Apply buildconfiguration's addToEnvironment first,
only then apply the kit's addToEnvironment.
This does change a few things:
* CMake and Qbs will now get the normal PATH
* MSVC compilers will have their compiler path prepended to PATH
by the effected BuildConfigurations. This should be harmless,
since that happens before the environment setup script is appended.
Task-number: QTCREATORBUG-18714
Change-Id: I548182bc447d80d24f4de4ce7cf12ee1a753ed26
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
To avoid repeating the 'MimeDatabase mdb; mdb.something(); ' mantra
all over the place.
Change-Id: I4bfef62e73275a991455141671d6071162788e9d
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... instead of peeking into versionInfo().
in fact, make versionInfo() private, to avoid subsequent deterioration
as happened before (after 5e596e89d).
some other functions that use it in its interface also become private.
this fixes several breakages related to working with non-installed
prefix builds of qt.
Change-Id: Ib67de79323c9e38f3de48a09854b155de9eef5b2
Reviewed-by: James McDonnell <jmcdonnell@blackberry.com>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
If ProjectMacroExpander doesn't resolve it we fall back to the generic
ProjectExplorer resolution, which is likely to pick the wrong project.
Task-number: QTCREATORBUG-16724
Change-Id: I201b722c5fe184905f744a1f344ec46941f92ae3
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
BREAKS BACKWARD COMPATIBILITY OF TOOLCHAIN SETTINGS!
* Convert old ToolChainKitInformation to new version
* Store several toolchains in one kit (one per language)
Change-Id: Ia59a2ad067c57971ec34ce9b2e43758344443755
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
Sprinkle overrides over code derived from classes in ProjectExplorer
Change-Id: Ia4cc25649f7dc00b0ea126d8176a59afbc5ed574
Reviewed-by: hjk <hjk@theqtcompany.com>
