Based on Tobias Hunger's work from a few months ago.
The CMake configuration needs libclang and Qt paths specified as
CMAKE_PREFIX_PATH.
Auto tests are run with "ctest". At the moment the pass rate is 87%.
Change-Id: Iba98e39bf22077d52706dce6c85986be67a6eab0
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
For the command and the working directory.
Change-Id: Ia69dc7100aeb57bb6e1b35f4dd4f3cf3763d8cda
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
More consistent with the fromString case and avoiding false
conversions QString -> QFileInfo -> FileName in case the
inheritance of QString suddenly disappears.
Change-Id: Ib14646ab1a660fd45dd1ea6862a0b5faa52ad0e3
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
This was used wildly inconsistently. Use a setter instead in
circumstances where the context is reasonably clear.
The assumption is that this will always be done at some time in all
code paths.
Use a new 'Uninitialized' value to avoid triggering the first update.
Change-Id: I82c38cb9da3ccdbd8fbae8beefcbfa0e559ff794
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
First mechanical baby-step towards using aspects in IosBuildConfiguration.
Change-Id: I6eec5136ec05f0f26c3ca915fa7d84dccaafcb82
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Same result, less code, more fashionable.
Change-Id: I43b0fcc6e5efb5e394b1652c3c9b34871cbe2fee
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
For a long time, probably from the very beginning, a RunControl
was meant to hold (a copy of) data needed for its operation, that was
valid at the time of its construction, to be resilient in cases
where RunConfiguration setting were changed while the RunControl
was running, or to properly re-run with the original settings.
Unfortunately, the task was repetitive, as RunConfiguration
classes had no generic access to properties / "aspects"
and there was was the runConfiguration() accessor (probably
for mostly unrelated reasons in the output pane handling) which
made the idea of just casting that to the original runConfiguration
and access the data directly there appealing, with all the
expected consequences.
This patch here partially addresses the issue by copying some
more of the related data at RunControl construction time and
adjust the using code, avoiding most uses of the runConfiguration()
accessor in a mostly mechanical matter.
Complete removal appears possible, but will be less mechanical
in "difficult" plugins like ios, so this is left for later.
The new accessors in RunControl are very much ad-hoc, leaving
room for improvement, e.g. by consolidating the access to the
run config settings aspects with the other runconfig aspects
or similar. For now the goal is to remove the runConfiguration()
accessor, and to as much as possible fixed data after RunControl
setup is finished.
Next step would be to officially allow construction of RunControls
without a specific RunConfiguration by setting the necessary
data independently, removing the need for the various workarounds
that are currently used for the purpose of faking (parts of) the
effect of the non-existing RunConfiguration or refusing to operate
at all, even if it would be possible.
Change-Id: If8e5596da8422c70e90f97270389adbe6d0b46f2
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The interface of this function was rather unfortunate. In particluar,
the fact that it took ownership of the std::unique_ptr that was passed
in required some weird boiler plate code at all the calling sites.
Instead, it now becomes a proper factory function.
Change-Id: Iecdc6f6345232fc0f0a08bffaf8f1780edb57201
Reviewed-by: hjk <hjk@qt.io>
Mainly to get rid of the QProcess::finished deprecation warning.
Also adjust coding style in the surrounding connects when needed.
Change-Id: I12f9b248c7974b892c4a069356e578e80f8c59e9
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
All implementations that were returning true effectively did that
in case of node->buildKey() == rc->buildKey(), either directly or
in disguise of qmake's projectPath, so this is the check that is
used now in the two places where this is used.
The new global has the theoretical potential of return true in
cases where it did not before.
Change-Id: Ic5829de5fef0f9a04d516a3d9207685055823775
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Except for the DesktopDevice, which is kind of special. Also try
a bit to make (and partially fail at doing so) naming and code
structure (#include, use of namespaces) more similar to each other.
Change-Id: I9fe266e706b72c14f59ff03ca1ae02dba3adcc71
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... by a mechanism that doesn't require re-implementation in each
derived class.
A QtVersion's type() is uniquely defined by the supported type of
the factory creating it, so that factory can be found and used
for cloning. Non-base data is copied by a fromMap(toMap()) dance
as done in the project configurations.
As a side-effect, the *QtVersion copy constructors are not used
and not needed anymore.
Change-Id: I3aa5a0fd90a27dd115769e0573647cb5669641a0
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Derived implementation either used that as-is, or used the
result as part of their own operation.
Change-Id: I2817c4e6c6701ae647a70e77382dd30c8ea2bd2f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... by a functor checking some ad-hoc custom structure content.
This effectively replaces one ugliness (access to qmake specific
variable via qmake specific ProFileEvaluator) by an indirection
layer with similarly ungeneric contents, but I like the latter
setup better.
Change-Id: Iaee07c992fce4aabee2f4eae32a2413d772fe945
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... into a 'canCreate()' and the actual creation, which can be
done by the already registered m_creator.
Simpler interface, with the (temporary) regression that the
EmbeddedLinuxQtVersion get constructed twice, once only to
determine that it should be alive afterwards. Will be fixed later.
Change-Id: I5da2cafe473b25a0207bbd628632c9a259780361
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Use default plus polish afterwards instead.
Change-Id: Ibd137562128445a5bae5aaa4fc5fcce2df6c3e38
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Use two setters, one already pre-existing, to set autodetection
data instead of passing that through the create/contructor chain.
Change-Id: I8f9bdf2f82518aae765327a823bdea44210c2f96
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Test globally in advance instead. For two factories that means a stricter
check on the qmake executable but with qmake being a host tool the additional
exists/executable check should be in order.
Change-Id: Ib07ef19aeee2d0a19d4c38e178f3e20d22867c2c
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Same pattern as for the project configuration factories.
Change-Id: Ia2f85eb2d787965f7a49be3bfe0be20c3f2aed8a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Similar to the various types of project *ConfigurationFactory
Change-Id: I7b721f127c8bcc13c7db6880d36c79dd091bc037
Reviewed-by: Christian Kandeler <christian.kandeler@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>
This removes the IosPlugin::kitsRestored() member that does not
fully fit the standard plugin implementation pattern.
Change-Id: Iedd79e5326b85b189673c19e1920e21c34cd03bb
Reviewed-by: Eike Ziller <eike.ziller@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>
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>
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>
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>
They are not completely orthogonal, so use one function for
now.
This is the step towards streamlining the IDevice::ctor/create
lines of functions.
Change-Id: I1fe9144c45c7da0c9dcbda3bf424e976e0519cd6
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Second step towards streamlining the IDevice::ctor/create lines
of functions.
Change-Id: I8b0f2270a9f6545ff9419ef8cf44b456c2233223
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
First step towards streamlining the IDevice::ctor/create lines
of functions.
Change-Id: I44226f8a05902cadd40c8820ab67752070d186c0
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Our canonical style is
#include <utils/fileutils.h>
rather than
#include "utils/fileutils.h"
Which makes sense, as such headers will never be found in the local
directory.
Change-Id: I4ca46e90d6c4d19d4b1f235f4c79caad864ef222
Reviewed-by: hjk <hjk@qt.io>
