This avoids having .user files when pressing cancel on the Project Mode's
TargetSetupPage.
Change-Id: I09fc8e78c929d6f09a50ee57ef4f59555491c649
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Instead of hardcoding Core::ICore::mainWindow()
Change-Id: Iec7747945cbcb335ae552a0277a1527f598f1ff7
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
The PersistentSettings::writeFile needs it, and SettingsAccessor
should not hardcode it to Core::ICore::mainWindow()
Change-Id: I6ca99e9cd861fd81337028055fe0ed4d158b152f
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
So far only instantiates the .user file specific upgraders.
Change-Id: I9a16dfe4c3c61093ea1231413495eec2e8fe648e
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Change the preprocessor popup to a dialog.
Save the additional preprocessor directives to the session instead of the
.pro.user file.
Change-Id: I0d08c5684cfb21e822cde0a965c9cf14e5d6d47d
Reviewed-by: Nikolai Kosjar <nikolai.kosjar@digia.com>
Only methods as programming functions are affected. Besides renaming
some actions like "Switch Between Function Declaration/Definition" this
mostly touches (api) code comments.
This is a follow-up patch to commit 872bfb7.
Change-Id: Icb65e8d73b59a022f8885b14df497169543a3b92
Reviewed-by: hjk <hjk121@nokiamail.com>
Introducing a Widget with a SnippetEditor and a C++ Highlighter which
should provide additional information to the C++ preprocessor for a
specific file.
Change-Id: I27f9498c7e52d1493d6ea92a02a2c6d26130fe07
Reviewed-by: Erik Verbruggen <erik.verbruggen@digia.com>
Generalize the target setup page and move it into projectexplorer
Move the qmake specific code into a projectimporter class with
a specialization for qmake projects in the qt4projectmanager.
This change depends heavily on the BuildConfigurationFactory cleanups
done earlier and completes that change in such a way that generic
build configuration factories are now in theory possible. The
remaining problem is how to select the best factory of several that
claim to be able to handle a kit and that is left for the next patch.
Change-Id: I47134cb1938c52adebcdc1ddfe8dbf26abbbbeee
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Refactor the code of the build configuration factories. The idea is to
generalize the code so much that we can allow plugins to install
custom build configuration factories for the platforms they support.
To support this use case the following changes where done here:
* BuildInfo class was introduced to describe one build configuration that
can be created by a factory.
* Factories report a list of BuildInfo to describe what they can produce.
This fixes the need for factories to implicitly create one buildconfiguration
and then create another one 'officially' to support debug and release build
configurations to be set up for projects.
* Do no longer work around factories to create build configurations.
Change-Id: Ic372e4a9b5c582633b467d130538948472b89d91
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Fix grammar, punctuation, and style issues. Use standard wording for
QDoc commands. Remove \brief commands from function descriptions.
Move some function descriptions directly above the functions, so
that the \fn command can be removed.
Change-Id: Iedf4f0041af24541a982241f99bd4906e86af916
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Use it instead of retrieving this information from the document.
Change-Id: I809fcb2daf59021cf503c371a5d40d75d7448796
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
That is what it actually is, wrt how Qt API calls it.
Change-Id: Ied02055debf6aad75556b0d9d22e8ba2f72be555
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
QDoc does some magic with the \class and \namespaces
and \brief commands, so the following wording must be used:
"The xxx class yyy ..."
Change-Id: Id231f30e8464898b776888d5423523de404aae34
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Even if we supported several deployment factories, we will need a way
for projects to say that the normal deployment will not work for them.
Change-Id: I6d42ef22a8ff50cc6f2ec3307f2c1d3f2faf4ef9
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
#!/usr/bin/env ruby
Dir.glob('**/*.cpp') { |file|
# skip ast (excluding paste, astpath, and canv'ast'imer)
next if file =~ /ast[^eip]|keywords\.|qualifiers|preprocessor|names.cpp/i
s = File.read(file)
next if s.include?('qlalr')
orig = s.dup
s.gsub!(/\n *if [^\n]*{\n[^\n]*\n\s+}(\s+else if [^\n]* {\n[^\n]*\n\s+})*(\s+else {\n[^\n]*\n\s+})?\n/m) { |m|
res = $&
if res =~ /^\s*(\/\/|[A-Z_]{3,})/ # C++ comment or macro (Q_UNUSED, SDEBUG), do not touch braces
res
else
res.gsub!('} else', 'else')
res.gsub!(/\n +} *\n/m, "\n")
res.gsub(/ *{$/, '')
end
}
s.gsub!(/ *$/, '')
File.open(file, 'wb').write(s) if s != orig
}
Change-Id: I3b30ee60df0986f66c02132c65fc38a3fbb6bbdc
Reviewed-by: hjk <qthjk@ovi.com>
On initial run we offer the user a choice between all the kits, which
are compatible with the cached generator. After the initial run, the
user can't change kits nor generators anymore.
Except if the builds into a new directory or adds a buildconfiguration,
then the user can choose between generators but not kits.
Task-number: QTCREATORBUG-7940
Task-number: QTCREATORBUG-7928
Change-Id: I9b663435cd2e021f7fe08379c1c487a6aebe8976
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Reviewed-by: Peter Kümmel <syntheticpp@gmx.net>
Avoid using "." as includePath when it is unneeded
Change-Id: I9bc6f4ebe50409f49782520033fd5f098aed10d0
Reviewed-by: Christian Kandeler <christian.kandeler@digia.com>
Kit names are unique already, no need to try and make them more
unique:-)
Change-Id: I315387808aec790b85ee301f22984eda81608467
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Without the const QVariant can't be constructed inline.
Change-Id: I80ff9eb677361dca2fd104ef85facf7b69e580d7
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
And implement a tooltip for them
Task-number: QTCREATORBUG-7870
Change-Id: I4975dd24ca2b619ebcbd0393f97311590ed4930f
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Reviewed-by: hjk <qthjk@ovi.com>
Make it possible to add kits again after all kits were removed
from a non qmake project.
Task-number: QTCREATORBUG-7814
Change-Id: I38967cd4c106b95288b7020fe325d8cfe2688a7c
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
* Rename profiles to kits.
* Update some strings:
* projects mode has a Kits tab, not a Targets tab.
* " Settings" was dropped from the sub-tabs of the Kits tab
* menu entry "Build/Open Build/Run Target Selector" was renamed
to "Build/Open Build and Run Kits Selector".
* Use "Kit" instead of "Target" in miniprojecttargetselector.
(The class was not renamed as it does indeed select targets,
not kits)
Change-Id: I0727e086e2dfa0e8aaaf89fdc6f2e3596c7a4314
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
Do not save XML config files (profiles.xml, toolchains.xml, etc.)
if the file has not changed.
Change-Id: I5f0dea374b33a05e7c428f4031d53c83d92de595
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
It adds almost nothing and introduced some bugs.
This fixes:
Double evaluation in cmakeproject on build directory changes.
Wrong runconfiguration update in cmake for set_target_properties(target
PROPERTIES OUTPUT_NAME [..]) changes.
Unecessary runconfiguration removal in AutoTools and Generic projectmanager.
Reevaluation of .pro files on changing the active runconfiguration or deploy
configuration.
Task-number: QTCREATORBUG-7723
Task-number: QTCREATORBUG-7761
Change-Id: I50249b186917cd3a4f399f187f09ac8428ab6f9e
Reviewed-by: Tobias Hunger <tobias.hunger@nokia.com>
* Handle 0 when calling createTarget to avoid the crashes in the first place
* Do not try to create/add targets for 0 profiles to avoid creator writing
a warning to the console
* Fix possible crashes in debugger when no default profile is set.
Task-number: QTCREATORBUG-7695
Change-Id: I9afc8e29c8b859ad078dad794ef5017168daac78
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
