To HEAD of 1.13 branch. Also adapt to API changes.
Change-Id: Ibe35dfd19dea5f8cde254656cd471618645a0b07
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The authoritative source of information about a KitAspect is the
KitAspect itself, not the associated widget.
Change-Id: I72d3d0425b845457846a940350bab59f1ff0cc2c
Reviewed-by: hjk <hjk@qt.io>
A KitAspectWidget class is tightly coupled with the respective
KitAspect, and no one else ever needs to see any KitAspectWidget
subclass at build time.
Change-Id: I1883af3b054c225e1ff5dd913118715bfdbaacfc
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: hjk <hjk@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>
Output parsers are created elswehere these days.
Change-Id: I196d158747883df091f7b55354c3580515d9759e
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Originally, the build manager used to run all build steps in a dedicated
thread. Communication between the step and the manager happened via a
QFutureInterface that was passed into the step's run() function.
Later, new steps were added that operated asynchronously, so the build
manager had to differentiate between the different kinds of steps for
starting and stopping.
These days, almost all build and deploy steps work asynchronously, which
made the QFuture-based interface look increasingly odd.
With this patch, all build steps are expected to work asynchronously, so
the build manager no longer needs to differentiate. Steps are started
and requested to stop via the run() and cancel() functions,
respectively, and emit the finished() signal when they are done. Build
step implementors no longer have to deal with a QFutureInterface. For
steps whose implementation is inherently synchronous, the BuildStep base
class offers a runInThread() function.
Change-Id: If905c68b234c5a669f6e19f43142eaa57d594803
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>
... 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>
DefaultDeployConfigurationFactory used extra effort to not apply to the
Qbs (Desktop) case, with QbsDeployConfigurationFactory plugging exactly
that hole with essentially the same functionality, which is even the
default of the base class.
The only differences are the display name, which is dropped in this
patch, and the different keys in the .user file, which are updated
with this patch. Note that the display name "Qbs Install" for the
DeployConfiguration stays with this patch whereas a freshly created
one will get the default "Deploy Configuration" name.
Change-Id: I255371d0a0688fbc6303083eb6aa20563e876264
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Since the types are all the same now, no template is needed, and
effectively only m_configBaseId is set, so rename the function
accordingly.
Change-Id: I79bbf488a0549d78b6f3f0408e6744f71a5dc190
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
It was an empty shell around the base class.
Change-Id: I4e6dce0a559a940d20f90a25e02ce79166c17e3b
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... and use the QbsCleanStep as guinea pig.
Change-Id: Ic0d62700bf48fc7971a290c90394c74b8860b9ff
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The extra parameter was always computed but used only in one place,
and that use got removed lately.
Change-Id: Ie10c0107ca70ee97ce03f83294992aab8d1a3ffe
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Centralize gathering the kit, toolchains and qt version.
Change-Id: I6bd586ac7925e2ee556fd119f1dab096cd500e41
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This function is exactly the same as SysrootKitInformation::sysroot(),
except that is returns a boolean. And it's always used like this:
if (SysRootKitInformation::hasSysRoot(k))
sysroot = SysRootKitInformation::SysrootKitInformation::sysroot(k);
Which means that the same code is executed twice in a row.
There is no point in this, so let's just remove it.
Change-Id: I95e4de101d6164ed48558b888e22ed8892fc6d9b
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
...for the qmake project manager.
When parsing the project files, remember whether a file was discovered
by the exact or cumulative parse. Only files that were discovered by the
exact parse are considered "active" and thus part of the build
configuration. The others are not offered for selection.
Fixes: QTCREATORBUG-16016
Started-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Change-Id: I7a28b4de15e048975d7f0cd737dd8c11f744315b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Also remove the signal CppProjectUpdater::projectInfoUpdated() which is
now unused.
Change-Id: I65afe8f96cd8175edaf8ccb6e5067e4f9cd8d99f
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@qt.io>
- add a QString FileNode::buildKey(), returning the build key
for a build represented by that node, if any.
* for QmakeProFileNodes the build key is traditionally equal
to the file name, so use that.
* for QbsProductNode use the uniqueProductName()
- add a Project::findNodeForBuildKey(QString buildKey) convenience
function searching a Project(!)Node matching that build key.
That's the only use case there is right now, and I see no reason
yet to travers all files (yet).
Change-Id: I388c0e06c03111e12d630899d762448e974a5737
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The configuration name determines the build directory name, so make sure
we're not using translated strings there.
Fixes: QTCREATORBUG-21466
Change-Id: I9c1996f8fb532fbf26ec44db09ee157ca3c94844
Reviewed-by: hjk <hjk@qt.io>
+ fix display of install root with variables in equivalent command line.
Change-Id: I9f8ab6dba80afddd0ee5116947c11752ded8129f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... of the build step widget. By "special properties" we mean those for
which a dedicated UI element exists.
Fixes: QTCREATORBUG-21363
Change-Id: I8b136798340c1a2cdc178451247a9f1f77d91dd7
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
From a virtual function to a normal one backed by a real data member.
That's essentially what several re-implementations did, the other
ones used a fixed value instead.
Change-Id: I61e45f1d4f7f0f80fe2eb1f2729785f37e7bb803
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Use BuildStep::displayName() as default.
This probably could be the only possibility, but currently there
are some discrepancies that are kept in this patch to make
the patch mechanical.
Change-Id: I2a1e5c2ff37ad95e25309eb16e07099e42191f60
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Instead, set the default level of all logs to QtWarningMsg.
The call to setFilterRules overrides the user preferences in qtlogging.ini.
Change-Id: Id5f6cd550d14ff7f45ae04c5d3110e0bafb0f072
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: hjk <hjk@qt.io>
The extra m_step member is not worth the abstraction, especially
since almost all non-SimpleBuildStepWidget have something similar,
too. Also, as several derived classes needed to correct
SimpleBuildStepWidget's setShowWidget(false).
Change-Id: I6e80d8c84c363b90dc27c70abd7fa6cefa1ed91e
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
We checked the command line from the project manager for "-std=X" and
friends to figure out the language version to use. However, if such a
flag was not provided, we assumed the latest version we support. This
could conflict with the actual version of the compiler and its
predefined macros.
Figure out the version by inspecting __cplusplus/__STDC_VERSION__ in the
predefined macros of the toolchain. The MSVC compiler is an exception to
this, as it does not seem to properly set the value - check for
_MSVC_LANG if possible, otherwise simply assume some versions as before.
While at it, add also support for C17/C18 and the upcoming C++2a.
Task-number: QTCREATORBUG-20884
Task-number: QTCREATORBUG-21188
Change-Id: I464ffcd52d2120c0208275a050e82efda44fae1c
Reviewed-by: Ivan Donchevskii <ivan.donchevskii@qt.io>
...by using Utils::ElidingLabel rather than a plain QLabel in
QbsKitInformation.
Change-Id: I4014ee918f0ea712a2975ffb4638c495fd8e0c71
Fixes: QTCREATORBUG-21102
Reviewed-by: hjk <hjk@qt.io>
Using aspects is the standard pattern nowadays, there's nothing 'extra'
to them anymore.
Change-Id: I446f9d7b1db58a4899e5e44df33ce51f655e7be4
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
It is documentation related API, so it belongs there.
Change-Id: I5d1676f251e6deb92050ddedac19bf3c332aab54
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
... and adapt constructors to not take the now-unneeded
RunConfiguration pointer.
Change-Id: I53ff338f51334ff7b0c22d4bed92bfcfc8225ea7
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
It is the type used by the HeaderPath class, so reflect that in
the name.
I also considered to rename HeaderPath to IncludePath, but
that name is reflected in a lot of users, which would also need
to be adjusted for consistency. That would blow up the patch size
for little value IMHO.
Change-Id: I51421dbd3ab8b2874dc32fc82dc394c9b93ce5e9
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
This was one of the genuine users of the run config pointer in the
aspect base class. Instead of using that stored pointer to retrieve
the relevant environment aspect pointer later, pass and store this
env aspect pointer at construction time.
Change-Id: Icbdeb9ad0fe341e4003fb544c542064801aa170f
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
System include paths are appended after other includes by the compiler. So
we should set them as system includes and not as normal includes. Otherwise
we change the include order. Headers in system include paths are not
cluttering the screen with unwanted warning and by the way improve
performance too.
ProjectPartHeaderPath was a dopperganger of HeaderPath, so we merged them.
Change-Id: I7c394b4098b697de79761499ffcd5913cc02d652
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
The run configuration is known at setup time, and fixed.
Change-Id: Iad7837bf39fb5eeed49bd71b7f14b9692014ea9d
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
