Only the original one is implemented so far, but at least
in theory backends for retrieving data from cmake can now
be switched at runtime.
Change-Id: Id73a81c7d40f078be95defd30a38511dca3a3720
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Continue to concentrate all the code reading random cmake files in
BuildDirManager. Now the task is to clean up the code, make it less
dependent on values it should not depend on (kits, etc.), make it
handle changes better and finally add another implementation that
uses the cmake server mode to extract the data.
Change-Id: I533625e376b969b64287bc205bd2e4be7a605306
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Make sure to run cmake *before* cmake --build when cmake files just
got saved. This helps e.g. when editing CMakeLists.txt files and the
hitting "Built" and "Save all" (or "Always save before build").
Task-number: QTCREATORBUG-16187
Change-Id: I16b1d02eb342a447003380946ce7a9d785476a0e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This will make it easier to introduce a new type of BuildDirManager
to accommodate cmake server-mode.
Change-Id: I989aab9df44dff1cfdff226ef97bb30bb092ffdd
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
This is in preparation for having support for cmake's server
mode.
Change-Id: I6cc04fe7c5132c491c3f3c0f46560b8ad88808e8
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Rip out QFileSystemWatcher and use Qt Creators IDocument for file
watching instead. The latter properly delays any action till creator
gets focus again.
Task-number: QTCREATORBUG-16354
Change-Id: Ibb71963416b09712a80ee95347425550453b7fd4
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
With this patch it is possible to specify QML_IMPORT_PATH in
CMake projects and QtCreator will scan those paths.
One only has to make sure that the variable which is set in the
CMakeLists.txt is also added to the CMakeCache.txt
Task-number: QTCREATORBUG-11328
Change-Id: I11c7694806664d3203d855983e7db4a89fac267d
Reviewed-by: Thomas Hartmann <Thomas.Hartmann@theqtcompany.com>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This still fixes the parsing issue when switching build configurations,
but the code is simpler.
Change-Id: I5748788224c5b49399550c33bcef592f193cfa8a
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
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>
* 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>
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>
Done using the following ruby script:
Dir.glob('**/*.h').each { |file|
if File.file?(file)
s = File.read(file)
t = s.gsub(/^namespace .+ \{\n\s*class .*;\n\s*\}.*$/) { |m| m.gsub(/\n\s*/, ' ').gsub(/\s*\/\/.*$/, '') }
if t != s
puts file
File.open(file, 'w').write(t)
end
end
}
Change-Id: Iffcb966e90eb8e1a625eccd5dd0b94f000ae368e
Reviewed-by: hjk <hjk121@nokiamail.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>
It's the coding style and this makes it consistent in this file
Change-Id: I6d99651eea2ffc161ecf3efc50a1ed71eaf67aa0
Reviewed-by: Tobias Hunger <tobias.hunger@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 cmake wizard proposes also ninja if ninja support is available
Ninja must be in PATH, but it is only called once, so it doesn't hurt.
Task-number: QTCREATORBUG-7720
Reviewed-by: Daniel Teske <daniel.teske@digia.com>
Change-Id: If3c9c7ae55e6990fa16b031fc2998a8d8d9ed17a
Reviewed-by: Peter Kümmel <syntheticpp@gmx.net>
Reviewed-by: Yuchen Deng <loaden@gmail.com>
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
CMakeBuildConfigurations can only exist on CMakeProjects
Change-Id: I8501e39f133fea854b953f9739e001cae1f2c0ea
Reviewed-by: Tobias Hunger <tobias.hunger@nokia.com>
