Instead of hardcoding a Qt Creator path into the standalone Qml
app .pro file by assigning a value to QMLINSPECTOR_PATH, we let
Qt Creator set that value as command line argument when calling
qmake.
QMakeStep::allArguments() is the place where it is added right
dt will will certainly suggest a better place place for it.
* Add a DeployConfiguration class to hold settings related
to deployment.
* Add BuildStepsList to hold a list of buildsteps
* Update BuildConfiguration to use BuildStepLists instead of
manageing lists of buildsteps itself.
* Update BuildManager to use BuildStepLists in its interfaces
* Fix fallout introduced by API changes
* Update .user file to new way of storing settings
Task-number: QTCREATORBUG-1427
Task-number: QTCREATORBUG-1428
Task-number: QTCREATORBUG-1811
Task-number: QTCREATORBUG-1930
Using more *::Constants::ICON_* where it makes sense and
wrapping the file names into QLatin1String where they were
missing.
The increased usage of the ICON constants needed a few more
cross plugin includes of *constants.h, here and there.
I think that it is OK, since the dependencies were alredy there
icon resource wise.
This fixes QTCREATORBUG-1434, but it's more of a workaround than a fix.
The problem was that the file was opened in the diff editor due to a
broken diff detection, and the diff editor in turn has a bug in that
it's kind of halfway read-only.
Reviewed-by: ossi
Task-number: QTCREATORBUG-1434
This is a big change touching almost all of our .pro file parsing.
With this patch we only evaluate once exact for all needs and once
greedy for the filelist. That is the qt runconfigurations don't have own
evaluaters but reuse the project wide exact evaluation.
We reevaluate if the user changes the build directory, the qmake
buildconfiguration or the qmake arguments. That is if you open src.pro
(or projects.pro) of qt with a shadow build you still don't get all the
files, but after correcting the build directory, we reevaluate the .pro
files and find all files. So for a suitable definition of fixed, that
bug is now fixed.
We now get the exact defines of all .pro files instead of all defines for all
buildconfigurations. We still don't distinguish in which
.pro file a DEFINE is set. So the code model now knows about all the
defines set for the given configuration but not for which files it is
actually set. Also that includes all DEFINES set in .qmake.cache or the
mkspecs. This means all defines from .pro files should now work.
The intial loading is still synchronous. I haven't looked into it to
deeply, but it seems possible to make it also async.There are probably a
few issues which need to be solved fist.
Also due to the asynchronous nature of the code, the executable is
updated a few seconds after actually changing the build configuration
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
Added translation macros to some editor kinds.
Added possibility to translate names of editors in Open With context menu. Translation context is "OpenWith::Editors".
Merge-request: 808
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
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.
