aboutsummaryrefslogtreecommitdiffstats
path: root/src/plugins/projectexplorer/runcontrol.h
Commit message (Collapse)AuthorAgeFilesLines
...
* Utils/ProjectExplorer: Move re-usabled bits of aspects to Utilshjk2020-09-231-1/+1
| | | | | | | | | | | Classes involved are BaseAspect and some derived classes, LayoutBuilder and VariableChooser. This is mostly mechanical, with various include/using changes to make it compile. Change-Id: I624a457f3555f102e541c4c71e33a9423af32250 Reviewed-by: Eike Ziller <eike.ziller@qt.io>
* ProjectExplorer: Properly set up the output formatterChristian Kandeler2020-09-041-1/+2
| | | | | | | | ... for the app output window. Fixes: QTCREATORBUG-24560 Change-Id: I199d7b16f445db498027094792c6cf344d920a88 Reviewed-by: André Hartmann <aha_1980@gmx.de>
* Core/Utils: Migrate further to Utils::Idhjk2020-07-061-14/+14
| | | | | | | | The coreplugin/id.h header is kept for downstream for now. Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66 (cherry picked from commit 430a33dcd9ac80ddb848e41f8f059102857c88aa) Reviewed-by: Eike Ziller <eike.ziller@qt.io>
* QtSupport: Add QtTestParser to the list of output formattersChristian Kandeler2020-04-281-2/+3
| | | | | | | | | ... when creating a run control for a Qt project. Now tasks will appear in the issues pane for QtTest application output in the app output pane. Task-number: QTCREATORBUG-22665 Change-Id: I2674f3d4f9aabc0a4db4178dcd5495b822f14022 Reviewed-by: hjk <hjk@qt.io>
* OutputFormatter: Take ownership of the line parsersChristian Kandeler2020-04-151-1/+1
| | | | | | | | For symmetry with IOutputParser. Task-number: QTCREATORBUG-22665 Change-Id: I92e93b32e87ff4f3fa163a2d2fe13768e56bfa24 Reviewed-by: hjk <hjk@qt.io>
* Utils: Split up OutputFormatter classChristian Kandeler2020-04-141-5/+5
| | | | | | | | | | | | | | | An OutputFormatter takes some string and prints it into a text edit. In addition, it can ask any number of registered OutputLineParsers whether they think any special formatting should be applied to the current line. This mechanism is now properly modeled by our class design, rather than being hidden in a monolithic class where everything had the same type, no matter what its purpose was. Prospective contributors can now simply be pointed to the OutputLineParser class and will see at one glance what they have to do. Change-Id: I9844499f062c94fb038ce73fd6f26576910148c2 Reviewed-by: hjk <hjk@qt.io>
* Remove the limitation that output formatters have to be exclusiveChristian Kandeler2020-03-201-2/+2
| | | | | | | | | | | | Introduce an aggregating output formatter that forwards its input to a sub-formatter that feels responsible for it, or otherwise lets the base class handle it. Our output panes now use such an aggregating formatter. In particular, this means that in the future, we won't have to stuff all run control output formatting into the Qt output formatter anymore. Change-Id: I5498f200a61db10ccff3ec8974c6825da7f7072d Reviewed-by: hjk <hjk@qt.io>
* ProjectExplorer: Replace ProjectConfiguration::m_macroExpanderhjk2020-02-191-1/+1
| | | | | | | | | | ... 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>
* ProjectExplorer: Store parts of active build config in runcontrolhjk2019-09-241-0/+4
| | | | | | | | ... 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: Store some aspect data by value in the RunControlhjk2019-09-051-1/+2
| | | | | | Change-Id: Idb7e119b5b0b483ce91efeb21fb415b654cfed4f Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Christian Stenger <christian.stenger@qt.io>
* ProjectExplorer: Use std::function for SimpleTargetRunner::start()hjk2019-09-041-12/+8
| | | | | | | | | This spares us the typical r = runnable(); modify(r); setRunnable(r) roundtrip and the m_runnable storage that might or might not be the same as runControl->runnable. Similar for m_device. Change-Id: I8300260dd8dd7cd395e40bcd3d2ae45089085008 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
* ProjectExplorer: Remove traces of previous attempthjk2019-08-301-7/+0
| | | | | | | | | | | ... to access runconfig aspect data in a generic way from the runcontrol. The plan is now to use a Kit-style variant map with some helper functions for type-safe(r) access. Change-Id: Ia3855758be3fce4efd423b83f185d0df88d266f3 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Standardize RunWorker creation logichjk2019-08-271-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This unifies the remaining paths of RunWorker creation to always use RunWorkerFactories in the plugin pimpls. There were, and are, still effectively three basic kinds of workers: - "toplevel" tools corresponding to the run modes, that are often all that's used for local runs and directly started via the fat buttons or e.g. entries in the analyze menu, with factories already previously located in the plugin pimpls - core "tool helpers", providing tool specific functionality typically used in conjunction with a remote device specific run mechanism, set up via RunControl::registerWorkerCreator - target/device specific runhelper like port gatherers contructed e.g. via *Device::workerCreator(Core::Id id) Worse, these categories are partially overlapping, so it was not clear how a "clean" setup would look like, instead some ad-hoc cobbling "to make it work" happened. In some cases, the runMode id was used throughout the whole ensemble of run workers for a given run, and which worker exactly was created depended on which of the mechanism above was used in which order. With the new central setup, the top-level runmodes remain, but the second kind gets new ids, so the implicit dependencies on order of setup mechanism are avoided. This also helps in the cases where there was previously unclarity of where and how to set up worker factories: It's always and only the plugin pimpl now. Change-Id: Icd9a08e2d53e19abe8b21fe546f469fae353a69f Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* ProjectExplorer: Add a facility to dump supported run worker setupshjk2019-08-201-0/+3
| | | | | | | | | | | Essentially walking the RunModes x RunConfigs x Devices cubes. Information is just the factory pointer, or null, some name would be nicer, but for now it turned out to be sufficient. Change-Id: Ifdf92b2353cb5c0346ee4566beb7d78a00645aed Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* Utils/all: Create an OutputFormatterFactoryhjk2019-08-131-0/+17
| | | | | | | | | | | Essentially following the scheme used for the various project configurations. This makes it possible to construct OutputFormatters by Id only, potentially reducing hard plugin dependencies and opening the road to have several output formatters per RunConfiguration/Outputpane/... Change-Id: I4b5fb6fb6be8b0d9a0859f178bb0effc3398b09e Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* Project: Push direct RunConfiguration use out of RunWorker factorieshjk2019-08-131-2/+2
| | | | | Change-Id: Ie5a5771bcaed7085494d5875b42668ee8d6dc157 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
* ProjectExplorer: Re-work setup runworker factorieshjk2019-08-091-48/+16
| | | | | | | | | | | | | | | 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: RunControl header cleanuphjk2019-08-071-4/+0
| | | | | Change-Id: I6f3a838ef6ed72827c3db582414b92d355e9320d Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Replace RunControl::buildTargetInfohjk2019-08-071-2/+3
| | | | | | | | | | | ... 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: Use Utils::FileName for Runnable::executablehjk2019-06-211-3/+4
| | | | | Change-Id: I584bc18aa19a4c9886af7b13e95052dfd4350b34 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
* ProjectExplorer: Add a Runnable::setCommandLine()hjk2019-06-031-0/+1
| | | | | Change-Id: I9b6a782e143dca8519cdc57171557bd3893df921 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* Utils: Extract a CommandLine structure from a QtcProcesshjk2019-05-291-0/+3
| | | | | | | | | | | | 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>
* ProjectExplorer: Make it easier to use RunConfiguration idshjk2019-04-051-0/+4
| | | | | | | | | | ... in RunWorkerFactory. The semantics is the same as in the other {RunConfiguration,BuildConfiguration,...}Factory::addSupportedFoo cases: As long as none is specified, there's no constraint, if there are any, it's a whitelist. Change-Id: Ia05afd9afe6886e4bacc58ac786f2548f03e5ca8 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Switch order of template parametershjk2019-04-021-1/+1
| | | | | | | | | | | | | ... of SimpleRunWorkerFactory. This requires being explicit about the SimpleTargetRunner worker default, but makes the template re-usable for current users of RunWorker::registerWorker() which I would like to phase out now, for less variations in the RunWorkerFactory setup. Change-Id: I32638437e5bb29f143650f5fde706711ab25accf Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Remove RunWorker::runMode()hjk2019-03-211-1/+0
| | | | | | | Only used once, and that use can be replaced. Change-Id: I844254dfff9bb2b2c9c56ecbd56d2af2241fd2d8 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
* ProjectExplorer: Replace one overload of RunControl::registerWorkerhjk2019-03-201-8/+0
| | | | | | | | | | ... by using factory members in the plugin pimpl. This also (intentionally) transfers ownership of the factories to the plugins, effectively progressing on the "FIXME:" in runcontrol.h:164. Change-Id: Ia75ee034d25a75b5d5bff6b2fa2b3471347d1a14 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
* ProjectExplorer: Replace RunControl::producerhjk2019-03-201-1/+2
| | | | | | | | | | ... by two more specialized canRun() / createMainWorker() functions resulting in somewhat leaner code on the user side and paving the way for introducing a RunWorkerFactory class intended to follow the now-canonical way of having factories as members in the plugin pimpl. Change-Id: Id6fc2043a340203f14ab0b896a8dfa1e298f58a6 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
* ProjectExplorer: Introduce a SimpleRunWorkerFactory templatehjk2019-03-191-0/+16
| | | | | | | | | | | | | | | ... and use in as replacement for RunConfiguration::addRunWorkerFactory. It is still convenient to have a simple way to set up run worker factories for the typical "just run for this configuration" case, but it's even better if it follows the nowadays predominant pattern of keeping factories in the plugin's pimpl. Also, it turned out there were two copies of QmlProjectRunconfigurationFactory code, one is enough. Change-Id: I0b28c4ea18d0f52165a49f6133dc8687a3b9c7cf Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Move RunControl related classes to separate file pairhjk2019-03-131-0/+330
Change-Id: I5da56f80336673d595907abcc797f628be680cd5 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-13 03:41:34 +0000