This has still a few missing things, but this enough to start getting
some feedback. Missing are non qt projects, a solution for the
runconfiguration, a missing black line between the treeview on top and
the project settings at the bottom. Some flickering with removing/adding
widgets to the QScrollArea and not showing the expanded widget if the
Details button is right at the bottom.
It works, except that the code model doesn't get the rvct include
directories and defines yet. And you need to have everything for
rvct set up in your environment.
Don't add -spec foo to the additional Arguments if foo is the same as
the default mkspec. This makes the common case better, while breaking if
you have QMAKESPEC set in teh environment and used -spec foo to override
it.
Create a new one and check if it's the same as the old one,
has the advantage that cached data doesn't need to be retrieved again.
It was that way before tool chain was moved to Qt4Project.
E.g. cmake pops up a wizard then, the running of cmake can fail though.
Now you don't end i[ with a empty project then. The error reporting in
that case is not yet optimal.
Note: This code should be shared between Qt4RunConfiguration,
CMakeRunConfiguration and CustomRunExecutable. Also we are approaching
other IDEs like configuraion options for setting the environment.
Without having a good GUI for that. I'll probably be redesigning this
for 1.3 or 1.4.
At this point, compiling projects and debugger helpers works.
The speciality with this is that Qt does not provide distinct
mkspecs, because MSVC draws the line between 32 and 64 bit
solely by the environment.
This means, creating a new project, we immediately have completion for
the ui file. Also adding stuff to the ui file now changes the codemodel
immediately.
Yet todo, are tests under windows and suppressing a warning if the form
contains a toplevel spacer.
Qt Creator wouldn't find the correct target if shadow building a project
that uses $$OUT_PWD, like for example itemviews-ng.
We didn't set the necessary variable on the ProFileReader *, simplified
the code to always use a ProFileReader created for the exact
profilenode.
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.
Task: 247606
Details: Remove all the magic which build on top of the cumalative
parser. Instead trust the exact parsing to get those variables correct.
This required a bug fix in the profile evaluator, done with ossi.
Hopefully this doesn't break windows/mac. Will check.
Made the cmake plugin even more usable by implementing:
Pop up a wizard if there is a .user file but no .cbp file. (Fixes empty
project reported on irc.)
Pop up a wizard if the .cbp file is older then the CMakeLists.txt file,
thus reparsing the file. (Note: There is a bug that we need to actually
also check the last modified of all included files.)
Reparse the cbp file to add new RunConfigurations / delete no longer
existing RunConfigurations and update those that have changed.-
Show a nicer title in the Projects/RunConfiguration pane
