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>
The method is used to reset the build directory if shadow building
becomes unavailable due to the Qt version changing. It does not
explicitly emit anything anymore.
Change-Id: I27b46b77f334be62f4db5f269529f8a2d62d834b
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
That is necessary so that the executables get updated.
Task-number: QTCREATORBUG-10107
Change-Id: I42e3ce38a5824e285546c43a3ec0045b090c6af5
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Use setBuildDirectory() in the different BuildConfigurations instead
of reimplementing that over and over again.
Change-Id: Ic355fdb4624c71667ce470b3e2865c9a8722ef09
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Tobias Hunger <tobias.hunger@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>
They serve no purpose, the default target in debug_and_release Makefiles
is to build only debug or release.
Change-Id: I4e403a2d25e09c8f31a4619d7588bfb34a5acf5e
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Ran script to remove inludes on a trial-and-error basis and
manually corrected it.
Change-Id: I53fa1aafaf98fd3105ef35b595e4311854cf9cbc
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
The names and actual config did not agree.
Task-number: QTCREATORBUG-8562
Change-Id: I23b270199d2bea12024937e1f950eaf67873ee33
Reviewed-by: Tobias Hunger <tobias.hunger@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>
This changes the qt creator behaviour to be different from the command
line behaviour of qmake. That is it now matters which way the user runs
qmake.
Change-Id: I5763fb45f0508cde6fce80824dc9f3c935a00797
Reviewed-by: hjk <qthjk@ovi.com>
Pass both arguments to qmake. The assumption being that most
projects will not mix both Qt Quick 1 and Qt Quick 2. In the
case of others, debugging will be enabled only for the first
debugging client that is enabled. This is inline with the
current behaviour where debugging multiple engines is not
supported.
Change-Id: I90cd6c6ff559a3a7519ee3ee10690c0e8135c97b
Reviewed-by: hjk <qthjk@ovi.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Which simply returns a BuildEnvironmentWidget. A long time ago
BuildConfigurations had no environment, nowdays they do. So it makes
sense for all BuildConfigurations to have the BuildEnvironmentWidget.
Change-Id: I824c45df79a0dcd2b624bf67a4730fb5dab098bc
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Which asks each KitInformation for their parser, thus currently creating
a toolchain + qt chain if that is applicable. Remove all code that does
that by hand from various buildsteps/buildconfigurations.
Change-Id: I79a07ffd1dbe9a43bdbc838bc0098071aa412009
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
The BuildConfiguration already takes care of that on kit updates and I
can't see a reason to emit it for changing the build directory.
Change-Id: I58f13dbddf4d4c3f99b444de21c74326ee4ac182
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
Not just qt4 and cmake but also generic projects.
Change-Id: I4a7e86fb2dbf6c6e32b4da78953ad3199c554470
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
The canonical form of the -spec argument is a relative path if the
mkspec is a child of the mkspec dir. Since we resolve all symlinks for
the mkspec, we must do the same for the mkspec dir.
Task-number: QTCREATORBUG-7908
Change-Id: I24628c2d49ff7ad078caa6fd3896cb407d0d7906
Reviewed-by: Tobias Hunger <tobias.hunger@digia.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>
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>
Qt Creator's support for Symbian was at its peak in version
2.4.x. Nobody really verified it in Qt Creator 2.5 or 2.6.
It is most likely rotten. Let's remove it!
Also, the Symbian support code was spread throughout the whole
Qt Creator code base. The plugin interfaces evolved in the
meantime and target platforms like Android or QNX have 99% of
their code in separate plugins.
In case anyone wants to revive Symbian support in Qt Creator,
please create a plugin for it.
Change-Id: I56a758a3e2fd5b8c64d9aeb8f63d8e916c4883be
Reviewed-by: Alessandro Portale <alessandro.portale@nokia.com>
