aboutsummaryrefslogtreecommitdiffstats
path: root/src/plugins/projectexplorer/runconfiguration.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Core/Utils: Migrate further to Utils::Idhjk2020-07-061-9/+9
| | | | | | | | 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>
* ProjectExplorer: Update parts of RunConfigurationFactory docshjk2020-06-161-24/+46
| | | | | | Change-Id: I4b9addde8055cb07565eea1c62e4e5b47725ff48 Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io> Reviewed-by: Eike Ziller <eike.ziller@qt.io>
* ProjectExplorer: Consolidate RunConfigurationFactory::idshjk2020-06-151-4/+1
| | | | | | | | | | | | | | | | | | | | It was already only one id string with two names. Since it is not an id for the factory but the id of the created run configuration, settle of runConfigurationId() as accessor. The factory and id fields in RunConfigurationCreationInfo were redundant. factory always implies (runconfiguration)id (but not necessarily the other way round, in theory different factories are possible for the same runconfiguration type for different devices). So drop the id field here. In one case now factory pointers instead of ids are compared, but this is neutral there as this happens in a context of a fixed Target, device and project are fixed there, so id and factory are equally unique. Change-Id: I859aa91486a2dd4abfc7369540a3322d6ec6260d Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Remove Target::applicationTargets()hjk2020-03-251-4/+4
| | | | | | | That's BuildSystem::applicationTargets() nowadays. Change-Id: I01cf0a491e4cb289af08f529fd15c85bfcdf5493 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
* Merge remote-tracking branch 'origin/4.12'Eike Ziller2020-02-271-12/+4
|\ | | | | | | Change-Id: I4523ea36332772a310fd462df55683c93c61bb18
| * ProjectExplorer: Remove RunConfiguration::activeBuildConfigurationhjk2020-02-261-5/+0
| | | | | | | | | | | | | | Only used once, and the concept is undesirable. Change-Id: I7f28f8a20d6d1f003a6d8b18bbcfba343614625c Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
| * ProjectExplorer: Disentangle ProjectExplorer::updateRunActionshjk2020-02-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This enforces a linear pass through [static] ProjectExplorerPlugin::updateRunActions ProjectExplorerPluginPrivate::doUpdateRunAction [emit] ProjectExplorerPluginPrivate::runActionsUpdated instead of the previous direct emission of the signal from user code and connecting also the internal update to it. This is meant to simplify reasoning about execution order and maybe to help elimimating double executation. Change-Id: Id8cc41a46d9dec06afb5514855f2ae80560f3695 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
| * ProjectExplorer: Inline RunConfiguration::isActivehjk2020-02-261-6/+3
| | | | | | | | | | | | | | | | | | ... into the only internal caller. The use there is dubious to some degree. Change-Id: Icfa7437b3fdaa4dbd73fe9965a88abf4700cd3e0 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* | ProjectExplorer: Replace ProjectConfiguration::m_macroExpanderhjk2020-02-191-10/+9
|/ | | | | | | | | | ... 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: Call RunConfiguration::update() when restoringChristian Kandeler2020-02-181-1/+3
| | | | | | | | | Otherwise, the executable path will not be set right after cloning a run configuration. This is due to the fact that it's not a stored attribute, but is retrieved from the build system. Change-Id: I948a2765b5b5d7707b44a72fcde7559e2742284c Reviewed-by: hjk <hjk@qt.io>
* ProjectExplorer: Trigger full run config update when parsing finishedhjk2020-01-211-6/+4
| | | | | | | | | | | The update is meant to be cheap, and this makes it easier to reason about what state the ui is meant to be in after a parser finished. Also, make on in-object connection a normal function call. Saves cycles and bytes and also makes order of execution defined. Change-Id: I9a411cd2a1ed1e0cc677bf45a7a5ea367efd7d0b Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectManager: Add convenience Task subclasseshjk2020-01-201-1/+1
| | | | | | | | For Compile, BuildSystem and Deployment. Unclutters user code and reduces binary size. Change-Id: Ia18e917bb411754162e9f4ec6056d752a020bb50 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Replace RunConfiguration::doAdditionalSetuphjk2019-12-171-1/+1
| | | | | | | | | ... by an explicit update() call. This is what effectively done in most cases, and should be harmless and reasonably cheap in most other cases. Change-Id: I323112ec7cdbccf19050ac54466d8e1d97a0516e Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Rework RunConfiguration::isConfigured()Christian Kandeler2019-12-051-14/+5
| | | | | | | | | | | | | | | | | | | | The old code had a number of problems: - There was one function isConfigured() to report whether the run config has issues, and a second one, ensureConfigured(), needed to be called to retrieve the details. At least one subclass implementor forgot to re-implement the first one, so the second one was never called. - The ensureConfigured() function could show a dialog and thereby delay execution of the run configuration, leading to additional state and a more complicated execution logic. Also, the dialog duplicated the run configuration UI. We now have only one function returning a list of Task objects. If the list is not empty, we present them to the user in a non-blocking way and abort the execution. Change-Id: I5f2a8126a2c1bd2ca51345b9e37b979bfc0c0b98 Reviewed-by: hjk <hjk@qt.io>
* ProjectExplorer: Provide the option to build only the app to be runChristian Kandeler2019-12-051-0/+8
| | | | | | | | | | | | | ... instead of the entire project. This can speed up the development cycle by ignoring irrelevant changes in the project, potentially at the cost of missing parts that actually should be re-built (in particular with build systems where a product does not have full knowledge of its dependencies). Supported by qmake and qbs for now. Change-Id: Ic7101aa243e92ba139798d13366d256c1919dcc3 Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io> Reviewed-by: hjk <hjk@qt.io>
* ProjectExplorer: Drop calling updates on RunConfiguration creationhjk2019-12-041-6/+0
| | | | | | | | | | Likely a leftover, and not needed anymore. All user visible RunConfiguration go through Target::setActiveRunConfiguration sooner or later, which trigger ProjectExplorerPluginPrivate ::activeRunConfigurationChanged which also updates actions. Change-Id: I9e7b570f74a83d353155249e183cee1755196c51 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Make enabled state updating part of runconfig updateshjk2019-12-041-14/+6
| | | | | | | | | RunConfiguration::update() is becoming a central place acting on requests to act on interesting changes, triggering notifications to "the outside" from there is natural. Change-Id: I159cb548c159a607e2628a178362987fb37b59e3 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Consolidate some Session::active* accesseshjk2019-11-291-14/+0
| | | | | Change-Id: I47b0f6c2c60b2f7c86b6ffd1ad3df393d1321c8b Reviewed-by: Christian Stenger <christian.stenger@qt.io>
* ProjectExplorer: Introduce a central mechanism to update RC aspectshjk2019-11-251-0/+11
| | | | | | | | | | | Using the usual pattern of setting a std::function, and calling it. In the initial steps, update() is meant to be manually called in the derived RunConfigurations, mid-term the idea is to at least cover well-known ("Kit changed", ...) cases centrally. Change-Id: Ic00572bb57fb45ef109bd0ddb8a9c3132d4f0f13 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Move BuildSystem owership to BuildConfigurationhjk2019-11-191-21/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ... 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>
* LayoutBuilder: Allow for more compact code at calling sitesChristian Kandeler2019-11-071-4/+2
| | | | | Change-Id: I12bb6dbfc138e03138b9a74d36e864d8ea36092f Reviewed-by: hjk <hjk@qt.io>
* ProjectExplorer: Prepare more flexibility to aspect layoutinghjk2019-10-181-7/+8
| | | | | | | | | | | | | | | | This hides the explicit use of a QFormLayout from the aspect interface in a new LayoutBuilder class. That currently works only on a QFormLayout in the back, but opens the possibility to use e.g. a QGridLayout as use on the Kits and some option pages. The aspects now only announce sub-widgets they like to add, actuall positioning is does by a new LayoutBuilder class, also cramming several widgets in an hbox in the right column of the QFormLayout is done there. Change-Id: I2b788192c465f2ab82261849d34e514697c5a491 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* Fix restoring cmake run configurationsv4.11.0-beta1Christian Kandeler2019-10-171-1/+6
| | | | | | | | Amends 5bcd59c94f. Fixes: QTCREATORBUG-22932 Change-Id: I46b42f0e15eaf1fe4bd2f1ea4a87286ee68cfee8 Reviewed-by: hjk <hjk@qt.io>
* ProjectExplorer: Run Settings: Move environment settings further uphjk2019-10-021-9/+16
| | | | | | | | | Adding the global aspects last, not first, more or less accidentally does the right thing. Fixes: QTCREATORBUG-22669 Change-Id: Iaf3eb4382974335471fff2f409ea4df7ef8f81b3 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Store some aspect data by value in the RunControlhjk2019-09-051-0/+8
| | | | | | Change-Id: Idb7e119b5b0b483ce91efeb21fb415b654cfed4f Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Christian Stenger <christian.stenger@qt.io>
* Remove usages of deprecated APIs of QLayoutSona Kurazyan2019-09-021-1/+1
| | | | | | | | | | Replaced: QLayout::setMargin() -> QLayout::setContentsMargins() QLayout::margin() -> QLayout::getContentsMargins() Task-number: QTBUG-76491 Change-Id: If28ef6910b3afe5d04e4746b74f9362a3e3b3c8e Reviewed-by: Eike Ziller <eike.ziller@qt.io>
* ProjectExplorer: Use a ISettingsAspect::setConfigWidgetCreator() setterhjk2019-08-301-3/+7
| | | | | | | Closer to the usual pattern elsewhere. Change-Id: Ieaed483bc7f61b63e5bde87a721f43c3e3d737aa Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Do not disable run configs because of project parsingChristian Kandeler2019-08-211-11/+6
| | | | | | | | | | | | After project parsing has ended, the run configurations are set up from the information provided by the parse, and that information is valid until the end of the next parse. There does not appear to be a reason to prevent users from e.g. editing command line arguments or starting the application just because the project is currently being parsed. Task-number: QTCREATORBUG-22548 Change-Id: Ib5e77c747fc2483650bcab22e07881ee7d93500b Reviewed-by: hjk <hjk@qt.io>
* Utils::Environment: Use expanded valuesChristian Kandeler2019-08-201-1/+1
| | | | | | | | | The Environment class is supposed to support values with references to other variables, but we failed to actually expand them in most places. Fixes: QTCREATORBUG-22687 Change-Id: I108cb59d3b4571471423455240f6f4f1cf64bf05 Reviewed-by: hjk <hjk@qt.io>
* Utils/all: Create an OutputFormatterFactoryhjk2019-08-131-8/+0
| | | | | | | | | | | 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>
* ProjectExplorer: Persist run config build keys as separate entryhjk2019-08-131-3/+11
| | | | | | | | | | The id mangling is not needed by the upper layers anymore, time to get rid of it in the .user files as well. For now, start storing the build keys explicitly, use that directly when present, and fall back to the old mechanism in cases we read settings without it. Change-Id: I1fa467a1488828ffd400e7d67d6fcd8247c938d1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
* ProjectExplorer: Use direct calls to signal update wisheshjk2019-08-021-7/+10
| | | | | Change-Id: I73d4a417f23bcf7fd8c9e16640e920100a6cce5a Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Add a ProjectConfiguration::target()hjk2019-07-291-10/+1
| | | | | | | | | ... with a suitable default implementation accessing a member populated at construction time instead of walking the parent chains on each access. Change-Id: I58dae6da80ed0b023cc603fca13a5a205b123672 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Replace RunConfiguration::executablehjk2019-06-121-10/+12
| | | | | | | | | | ... by a RunConfiguration::commandLine(). That's what is typically consumed, and removes the need for some custom runnable() implementations. Change-Id: I7700b12cdd0965802a0add977b432314734a5a72 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* Utils: Rename FileName to FilePathhjk2019-05-281-3/+3
| | | | | | | | 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>
* ProjectExplorer: Add an official way to connect aspectshjk2019-05-271-0/+2
| | | | | | | | | | | Aspects are not completely orthogonal, e.g. working directory depends usually on environment etc. So far handling this used ad-hoc set up in the (Run)Configuration constructor. Lets make this an official second phase, that also reduces the need to use a specific construction order of aspects. Change-Id: Ic98b7d4e1ac9d46a32ec624bbbbfbbc32a40ab32 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Add executable() accessor to RunConfigurationChristian Kandeler2019-05-241-2/+17
| | | | | | | Amends f6c276daf0, which was a quick fix for 4.9. Change-Id: I94281af6a9a0d0bfe197ce836488f708d5bd677d Reviewed-by: hjk <hjk@qt.io>
* ProjectExplorer: Expose working directory to macro expandershjk2019-05-151-0/+8
| | | | | Change-Id: I02ab3d4c4d850bc3c50186d4458b6a87d50a3926 Reviewed-by: Eike Ziller <eike.ziller@qt.io>
* ProjectExplorer: Remove BuildTargetInfoList wrapper classhjk2019-05-141-3/+1
| | | | | Change-Id: I1a2ae06ec8c5b7278abca2386834d7edd31597d7 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* Revert "ProjectExplorer: Upstream CMake's handling of outdated builds"hjk2019-05-031-10/+3
| | | | | | | | | This reverts commit 8536504caa216e599a6332261cd9fcafcbba296c. Break CustomRunConfigurations. Change-Id: I43020bd34780cb5fd02bbe640a817370d73cca18 Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
* ProjectExplorer: Merge StatefulProjectConfiguration into RunConfigurationhjk2019-04-051-1/+9
| | | | | | | | It's the only user, and single inheritance for feature reuse is an antipattern. Change-Id: I975861d111cec67fb2dbf94e38bd824d18a0c8d0 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Introduce a SimpleRunWorkerFactory templatehjk2019-03-191-11/+1
| | | | | | | | | | | | | | | ... 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-1464/+1
| | | | | Change-Id: I5da56f80336673d595907abcc797f628be680cd5 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Add RunControl accessor to configuration settingshjk2019-03-131-0/+5
| | | | | Change-Id: I30e8f27d4090576d38fe8a778d7fa508ac26cbfa Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Compile fix #ifdef WITH_JOURNALDhjk2019-03-131-1/+1
| | | | | Change-Id: I9566cd6319939d03f549f84302bf47db5c7cd9fe Reviewed-by: Christian Stenger <christian.stenger@qt.io>
* ProjectExplorer: Add RunControl::set{Kit,Target}hjk2019-03-121-4/+23
| | | | | | | | | For cases where no genuine RunConfiguration is available. Use it in the debugger for the cases triggered from the menu. Change-Id: I5671f4f5db2547c4a7a70bd34292bb6ccc8e6bf4 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Split RunControl constructorhjk2019-03-121-23/+29
| | | | | | | | | | | Into a trivial bit and two setters. Plan is to use it only with information that is truly there (e.g. kit/device only) at the user side without having to invent a RunConfiguration "handle". Also remove some dead code in the test runner. Change-Id: I987881e41722178b14b91f973b84cbdb67a9f85e Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* Avoid some visible uses of RunControl::runConfiguration()hjk2019-03-121-8/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* ProjectExplorer: Simplify RunControl::appendMessagehjk2019-03-121-5/+0
| | | | | | | Use a signal directly now, the users know the caller. Change-Id: Ib2ff4dbe3047eddf2a060eef060b487a4c17e78c Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
* ProjectExplorer: Improve error message in case of missing project filehjk2019-02-221-2/+7
| | | | | | | | | This was kind of done for AndroidRunConfigurations, but seems uniformly applicable as all projects have something like a "project file" currently. Change-Id: I48e1887ea900181b5bf42f75fb9412379a8320dc Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-19 17:43:59 +0000