Make shadowBuildDirectory(...) a static method of CMakeBuildConfiguration.
That way it can be used by a future projectimporter.
Change-Id: I1b3ffc821ac9197aa5c90e2b78891df7a81a31dd
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
This avoids creating lots of build directories as the user types
in something into the builddirectory line of the build settings.
Change-Id: Ib08a0f65e08bce104e4baf9e19fb01730d2f5f08
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
* Disable the BC and give report the cmake error
* Show a warning label in the BC
Change-Id: If5737d033fa2682c264ab7ac1189c59947e3b28d
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
Store CMakeConfig in CMakeBuildConfiguration instead of the list of
initialArguments.
Update initialArguments to a list of settings on load.
Change-Id: If58fc38296a4627f40062dd407e684c8a9477f6e
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
Do not push the cmake running straight into the face of the user. Do it
in the background instead.
This needs some follow-up patches to become really useful.
Change-Id: I3457178b33e3f14bdeac25005a773d17abb73b65
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
* Shorten header guards
* Use override and auto where possible
* Remove useless destructors, etc.
* Remove private slots sections, unify private: sections
* Use member initialization where it makes sense
Change-Id: I00eaf6d706adc16859176d1b68c631d3336bb39f
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
Do not bother to remember ninja support status now that it is no longer
used.
Change-Id: Ief24af8e39ad5e39633ccb6d31858fa003de5ce8
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
We define a Profile build to be a Release build with separate debug
info. You can thus change a given build from Release to Profile of vice
versa by toggling the separate debug info checkbox. The messaging for
future user interaction about Profile builds has to take this into
account.
Task-number: QTCREATORBUG-14009
Change-Id: I62a5b13993b20bf36329b1eefa8b1b6096f31644
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Some time ago the all the wizards for the Plain C++ were coalesced into one wizard.
Since then the wizard asks first for the targets via a targetsetuppage and then
in the CMakeOpenProjectWizard asked for the kit again.
This patch clean thats up, by always using the TargetSetupPage for kit
selection and removing code from the CMakeOpenProjectWizard for kit selection.
It also adds more types of buildconfigurations
Offer: Debug, Release, ReleaseWithDebugInfo, MinSizeRelease with the
corresponding -DCMAKE_BUILD_TYPE parameters. That argument is saved
in the build configuration and used once for the first cmake run. (Subsequent
runs of cmake don't require passing that to cmake again.)
Also do not require running cmake on creating the buildconfiguraiton, instead
postpone that until the buildconfiguration is made active. With the current
cmake wizard, selecting multiple kits would show a dialog per buildconfiguration.
Change-Id: I3bb806113f4f529f8e291830647d2515a6c4df8a
Task-number: QTCREATORBUG-12219
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Export CMakeProject to make it possible for plugins
to inspect the BuildTargets of a cmake project.
Change-Id: Ia7eb94689afefee7789e32ec009579856746787a
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
Preparing for exporting the CMakeProject symbol. Removing all APIs
from the header file that will continue to be interal API.
Change-Id: I820ea0efb909e6a75be70ccb3b419f841a15cfb3
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
When autocreating the name for a shadowbuild directory
the project directory name should be used instead of
the project file name. Otherwise CMakeLists.txt will be
used instead of the real project name.
Change-Id: If657b1527bfc5345243b8934d25fa4324580bebc
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
In ancient times we needed to support some qt versions that didn't support shadow
building. This code has been unused for some versions now, so remove it completely.
Change-Id: I311f255d6bfed6841e94c9c383bd9929d0d55520
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
All static functions, can live closer to related code.
Change-Id: I54c5680256c78f1d09b4bee3e8843b2f4350b75a
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
Since we want to treat them differently.
Task-number: QTCREATORBUG-12461
Change-Id: Ia72b8045390ceec693fa416f65010a4c4dbecce1
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Introduce priorities for build configuration factories. This way
plugins can register specialized build configuration factories, that
e.g. can provide additional build steps.
A negative priority signifies that a factory is not prepared to
handle a request, the default build configuration factory shipped by
the build system plugin will report a priority of 0. Add 100 to that
for each specialization you add (e.g. a remote linux buildconfiguration
factory would report 100, a specialization of that for mer will
should report 200, etc.).
Change-Id: I141a7a5a79166afdb7657d46eb7e86bd18d3abf6
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Reviewed-by: Michal Klocek <michal.klocek@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>
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>
#!/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>
