They do what you expect them to do, that is build only a subtree.
The implementation is a little bit strange. We temporarly set the sub
node to be built on the BuildConfiguration, enqueue that
BuildConfiguration (which calls BuildStep::init()), and then reset that
temporary value.
A more general way would be to have the ability to extend
BuildConfiguration::buildProject() in a way that additional data can be
passed to the BuildSteps.
Task-Nr: QTCREATOR-5
Task-Nr: QTCREATORBUG-44
* Use id() for methods returning a string used to represent
some type of object.
* Use displayName() for strings that are meant to be user
visible.
* Quieten some warnings while touching the files anyway.
* Move Factories to their products in the plugins where that
was not done before.
Reviewed-by: dt
* Rework IBuildParser:
* Remove name() method.
* Remove enterDirectory and leaveDirectory signals.
* Allow chaining of parsers.
* Rename IBuildParser to IOutputParser.
* Implement GnuMakeParser.
* Remove entering/leaving directory related code from all other parsers
* Move filename fixup heuristic based on entering/leaving directory
massages from gnumake here from AbstractMakeStep.
* Add outputParser method to ToolChain: This removes the need to map
toolchains to BuildParser names in the BuildSteps.
* Enhance AbstractProcessStep to accept a IOutputParser to parse its output.
* Remove AbstractMakeStep.
* Set the appropriate Parsers in all classes deriving from AbstractProcessStep
and append the ToolChain's parser to the parser chain.
* Remove BuildParserFactories: There is no more need for them.
* Remove constants used to identify the BuildParsers.
* Clean up some names:
* Replace stdOut with stdOutput.
* Replace addToTaskWindow with addTask and addToOutputWindow with
addOutput. Do this wherever it is not yet clear that this will end up
in the Task/Output window.
Reviewed-by: dt
Includes Maemo tool chain, run configuration, run control,
manager, etc.
Adds the DebuggerManager to the object pool. This is ugly, but
nobody came up with anything better on short notice. To be
refactored.
Co-Authored-By: kh1
and ApplicationRunConfiguration to LocalApplicationRunConfiguration,
preparing remote debugging. Change the interface canRun() to be const,
run() to create() (since it does not run anything), use references
to the QSharedPointer<Foo>. Introduce d-Pointer and remove
unneeded headers from ProjectExplorerPlugin and add missing includes
everywhere.
This removes the all hard dependencies to and from welcome screen,
except the one to the core plugin. More in detail:
- Add IWelcomePage to add a tab to the welcome screen
- Move tabs in the modules where they belong
- Enables QHelpManager to open help fullscreen and contextually
- "Getting Started" moves to Qt4ProjectManager
- Projects & Sessions (aka "Develop") moves to ProjectExplorer
- "Community" remains in the welcome plugin for simplicity
Add the wizard. Modify basefilewizard to use be able to handle binary
data. Add some properties to path chooser (filters).
Task-number: 251982
Initial-patch-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
The actions are already lazily instantiated in
TextEditorActionHandler::setupActions(), so there should be no need to
call initializeActions() in all plugins on startup. Only the main text
editor plugin will still initialize its actions, to make sure the menu
items are there.
Added IExternalEditor which knows a kind and a mimetype.
Make EditorManager and ProjectExplorer "Open With" query
the interface and add the respective kinds.
Add "openExternalEditor" to EditorManager.
Add External editors for Designer and Linguist,
making use of Mac 'open' or Designer's Tcp socket mechanism
to ensure files are opened in the same instance (per Qt version).
Task-number: 249392
Reviewed-by: con <qtc-committer@nokia.com>
We used to build a helper library as part of the project. First with the
qmake -after SOURCES= stuff and after until now with the
gdbmacrosbuildstep. Now, the all new and fancy integretation directtly
into the qt version dialog. You build the debugger library once for
each qt version and then it's there ready to be loaded into each
project build against that qt version. Saves a lot of time.
And makes it possible to also load that library into while debuggign a
cmake project. (Need to hook that up now.)
Unfourtanetly this breaks the custom dumpers if you use a custom run
executable.
Details: This enables us to parse the build errors correctly.
The makesteps of the qt4project and cmakeproject have some
code dupliaction, which could be refactored. And the code
to find out the correct build parser could probably also
be done better, but we are now parsing the build output for
cmake.
