summaryrefslogtreecommitdiff
path: root/src/plugins/winrt
Commit message (Collapse)AuthorAgeFilesLines
* BaseQtVersion: remove qmakeProperty(...) getterTobias Hunger2019-10-013-6/+7
| | | | | | | | | | | | 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>
* ProjectExplorer: Store parts of active build config in runcontrolhjk2019-09-242-5/+1
| | | | | | | | ... on runcontrol creation to prevent later access. Adapt some users. There are more to come. Change-Id: I2a3fe5eea0ada4eff7d08b79a6f49694e6962c8a Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Base IDevice::osType on a data memberhjk2019-08-192-6/+2
| | | | | Change-Id: I969563e6e62895a51fb4692c8eb0bab278f0ecae Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Re-work setup runworker factorieshjk2019-08-091-21/+13
| | | | | | | | | | | | | | | This combines two of the previous three paths to create run workers, and refers to RunConfigurations by id, not by type where possible to decrease coupling between the classes. Only allow "type of run configuration" and "type of device" as the only possible kind of restriction and require a uniform RunWorker constructor signature. Adapt user code to fit that pattern. Change-Id: I5a6d49c9a144785fd0235d7586f244b56f67b366 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
* ProjectExplorer: Replace RunControl::buildTargetInfohjk2019-08-072-5/+4
| | | | | | | | | | | ... by two accessors to the only used field. General idea here is to make the presence of a RunConfiguration in a RunControl less prominent to be able to remove it at some time completely, as the configuration's data might change while the control is running. Change-Id: I752540fadd135d6904fc9bf4e3506be074b0c003 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer::IDevice: Add a default display nameChristian Kandeler2019-08-021-1/+1
| | | | | | Task-number: QTCREATORBUG-16281 Change-Id: Ieff929343b5dc3a84d9ecf5f4f0a032cb4ae4076 Reviewed-by: hjk <hjk@qt.io>
* Some clang-tidy -use-modernize-nullptrhjk2019-08-011-2/+2
| | | | | Change-Id: I1bed5e85a5b7948d08502a72a10f80baa075c204 Reviewed-by: Thomas Hartmann <thomas.hartmann@qt.io>
* Utils: Add CommandLine convenience constructorshjk2019-07-232-2/+2
| | | | | | | | | | | | | ... taking a QString for the executable. This weakens the very explicit QString -> FileName conversion via the named constructors for the special case of constructing a CommandLine. I think that's worthwhile here, as it reduces the noise on the caller site under circumstance where the nature of the thing is obvious. Change-Id: I27b4a73639728893d053b2e7ba65cb745f0ffe83 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Prefer ProcessParameters::setCommandLinehjk2019-06-241-9/+9
| | | | | | | ... over setting command and args individually. Change-Id: Iec7c8d3a0b05fb8fa0639f7ddbe7ccdc7387d2a2 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Use Utils::FileName for Runnable::executablehjk2019-06-211-1/+1
| | | | | Change-Id: I584bc18aa19a4c9886af7b13e95052dfd4350b34 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
* ProjectExplorer: Make Device::displayType a data memberhjk2019-06-192-6/+1
| | | | | Change-Id: If650f660e3b10bc28d575ded07a854f59be26f87 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* Utils: Encourage marking of raw command line parametershjk2019-06-063-15/+14
| | | | | Change-Id: Id66ac07732c66ab8c1232fe1f58042de8a61abb0 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* WinRt: Use new Utils::CommandLinehjk2019-05-291-16/+16
| | | | | Change-Id: I7320f92199af439225233b6a1bcf0ec0b185cdcb Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* Utils: Extract a CommandLine structure from a QtcProcesshjk2019-05-292-2/+2
| | | | | | | | | | | | We regularly pass around strings or filenames or pairs of strings or filenames and stringlist etc the in the end will be used as a kind of "command line", with quite a bit of ad-hoc user code and QtcProcess::addArg etc to set them up and manipulate them. Let's have a class for that concept. Change-Id: I288ab939d853b32c717135a65242c584c2beab50 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* Utils: Rename FileName to FilePathhjk2019-05-281-4/+4
| | | | | | | | 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>
* Qt Creator CMake portCristian Adam2019-05-171-0/+16
| | | | | | | | | | | | | | 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>
* ProjectExplorer: Use Utils::FileName in ProcessParametershjk2019-05-151-1/+1
| | | | | | | For the command and the working directory. Change-Id: Ia69dc7100aeb57bb6e1b35f4dd4f3cf3763d8cda Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Use the fromMap(toMap()) pattern to clone deviceshjk2019-05-102-6/+0
| | | | | Change-Id: Ie6e73f5ef1019907dd311aac116d71f08b5a5202 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* WinRt: Use current plugin setup naming patternhjk2019-03-202-12/+4
| | | | | Change-Id: I13eddd9c92b41bfdc4964eecde64f9dd8f3cc147 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* WinRT: Remove a direct use of RunControl::runConfiguration()hjk2019-03-201-1/+1
| | | | | Change-Id: I1c8288a7620ba6dfd9ce99c67812e5122b654e07 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Move RunControl related classes to separate file pairhjk2019-03-132-2/+4
| | | | | Change-Id: I5da56f80336673d595907abcc797f628be680cd5 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* Avoid some visible uses of RunControl::runConfiguration()hjk2019-03-122-11/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Replace static_casts by QOverload where possiblehjk2019-02-262-4/+2
| | | | | | | | | 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>
* Move IDeviceFactory closer to IDevice implementationhjk2019-02-217-365/+293
| | | | | | | | | 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>
* ProjectExplorer: Introduce Target::buildTarget(buildKey)hjk2019-02-201-1/+1
| | | | | | | | | | | | | | A convenience wrapper for applicationTargets().buildTargetInfo(buildKey), the only context using the BuildTargetInfoList member. Also, only one of the free comparison functions is ever used, only in one place. Inline it there. Change-Id: I7565e9d51d429af34352649e235243e5b3328fe9 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* QtSupport: Replace BaseQtVersion::clone()hjk2019-02-194-24/+0
| | | | | | | | | | | | | | | | ... 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>
* WinRt: Include winrt.qrc in the qbs build systemAlessandro Portale2019-02-191-0/+1
| | | | | Change-Id: I9ebc5738b978ed71b1af21b24db59eb2948964d7 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* QtSupport: Provide implementation of BaseQtVersion::qtAbisFromLibrary()hjk2019-02-184-12/+0
| | | | | | | | 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>
* WinRT: Split WinRtQtVersion hierarchyhjk2019-02-182-1/+18
| | | | | | | | | To match the general pattern. Part of the code duplication can go later. Change-Id: I42f936bea88b4fc06f839045ba7988745f951ab7 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* QtSupport et al: Move QtVersionFactory to *QtVersion implementationhjk2019-02-189-102/+37
| | | | | | | At most a dozen lines each left. Change-Id: Ifbf34f814266ba7bee83d3fee9db831eb450dfc4 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* QtSupport: Replace QtVersionFactory::canCreatehjk2019-02-152-18/+2
| | | | | | | | | | | | ... 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>
* QtSupport: Split QtVersionFactory::create()hjk2019-02-152-16/+6
| | | | | | | | | | | | ... 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>
* QtSupport: Drop one suite of QtVersion constructorshjk2019-02-156-23/+6
| | | | | | | Use default plus polish afterwards instead. Change-Id: Ibd137562128445a5bae5aaa4fc5fcce2df6c3e38 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* QtSupport: Simplify use of QtVersionFactory::create()hjk2019-02-156-18/+14
| | | | | | | | 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>
* QtSupport: De-qobjectify QtVersionFactory hierarchyhjk2019-02-152-6/+4
| | | | | Change-Id: I6ceccf96f5f6a5dc4e33d667d4fc234e15b88926 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* QtSupport: Move qmake existence check out of *QtVersionFactory::createhjk2019-02-151-10/+0
| | | | | | | | | 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>
* QtSupport et al: Use more data members in QtVersionFactorieshjk2019-02-152-31/+4
| | | | | | | Same pattern as for the project configuration factories. Change-Id: Ia2f85eb2d787965f7a49be3bfe0be20c3f2aed8a Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* QtSupport et al: Centralize QtVersionFactory::restorehjk2019-02-152-22/+2
| | | | | | | Similar to the various types of project *ConfigurationFactory Change-Id: I7b721f127c8bcc13c7db6880d36c79dd091bc037 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* WinRt: Add a few 'override' to Qt versionshjk2019-02-152-10/+10
| | | | | Change-Id: Ie3547076d15363ec9995cee9b21bf8749725403f Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* WinRt: Split WinRtQtVersionFactoryhjk2019-02-153-19/+59
| | | | | | | | ... to get a 1:1 relation with produced Qt versions. This looks wasteful right now, but will be simplified in follow-up patches. Change-Id: I6bb1c087751cc6acdd0293410c02e1656da36050 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* ProjectExplorer: Rename KitInformation to KitAspectChristian Kandeler2019-02-115-7/+7
| | | | | | | | | | | 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>
* ProjectExplorer: Rework the build step run interfaceChristian Kandeler2019-01-312-8/+8
| | | | | | | | | | | | | | | | | | | | | 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>
* Merge remote-tracking branch 'origin/4.8'Eike Ziller2019-01-311-2/+2
|\ | | | | | | Change-Id: Ia8fed69168d87afafdb5acf4de4d5d30f9b4ebf5
| * winrt: Fix potential race condition when filling mapping file contentOliver Wolff2019-01-301-2/+2
| | | | | | | | | | | | | | | | | | Before starting the process step asynchronously, we have to make sure that m_mappingFileContent is initialized properly. Change-Id: I5a2b51319a35bfe397cff994d5f3512f8d76ccf0 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* | ProjectExplorer: Remove registerDeployConfigurationhjk2019-01-221-3/+3
| | | | | | | | | | | | | | | | | | 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>
* | ProjectExplorer: Remove DeployConfiguration::initializehjk2019-01-221-21/+6
| | | | | | | | | | | | | | | | | | ... and adapt remaining users. The function is now not needed anymore, all setup from the factory. Change-Id: Ibe77c3e55265309064bc8b840fd1129368cc70c1 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* | ProjectExplorer: Simplify BuildStep::init() signaturehjk2019-01-182-3/+3
| | | | | | | | | | | | | | | | 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>
* | WinRt: Streamline WinRt device constructionhjk2019-01-163-28/+8
| | | | | | | | | | | | | | Remove create() and init() functions and ctors except default constructor. Change-Id: I2746ca88bc1e63bdfb05d027c0816b3c8af5ea35 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
* | ProjectExplorer: Introduce a setter for IDevice origin and idhjk2019-01-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | 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>
* | ProjectExplorer: Use setter for IDevice::typehjk2019-01-143-4/+5
| | | | | | | | | | | | | | | | Second step towards streamlining the IDevice::ctor/create lines of functions. Change-Id: I8b0f2270a9f6545ff9419ef8cf44b456c2233223 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
View Lorry Controller Status