Due to a compiler bug the content of the raw string is
handled inside the preprocessor and the cmake comments
end up as being noticed as unknown preprocessor directives.
Change-Id: I3f235cfdd0799a6bb94743e2910663d9b0d3385d
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Visual Studio / Xcode generators are not setting the CMAKE_C|XX_COMPILER
variables, and when importing such a build the generated kit will have
no
compilers and won't be much of a use.
Luckily CMAKE_LINKER has the path to link.exe / ld, which is the same
path for the compiler cl.exe / clang.
Change-Id: Id21bb0ec2d5aa6ab5a185e03992477c433ac4798
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
CMake has multi-config generators like:
* Visual Studio
* Xcode
* Ninja Multi-Config
The first two have different special targets for "all", "install",
"package", "test" namely: "ALL_BUILD", "INSTALL", "PACKAGE",
"RUN_TESTS".
All of them need to get the build type passed via "--config <build-
type>" and not via "CMAKE_BUILD_TYPE".
The multi-config generators will use only one build directory.
Fixes: QTCREATORBUG-24984
Change-Id: I8aa7ff73ce2af1e163b21a6504d26fcf95530edf
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The CMakeCache.txt file has CMAKE_HOME_DIRECTORY pointing to the
project source directory used to configure the project.
When importing a cmake build the CMAKE_HOME_DIRECTORY from
CMakeCache.txt might not point to the same CMakeLists.txt that was
opened as a project.
qt-cmake-standalone-test from Qt6 uses a CMake template project which
does a add_subdirectory with the test source directory, which will not
work if opened standalone.
Normally this is a user error though, so ask the user if this was
intended, before actually importing the build.
Task-number: QTBUG-88776
Change-Id: Ifdd5e1d1cb8a1ef9955d22493eba3a1a55dc689f
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The code that detected the qmake path for the project stopped
working with Qt 6.0.
The new code will run a small CMake project that will output
the path of qmake from the CMake world, and not something that
Qt Creator does from outside.
Fixes: QTCREATORBUG-25100
Change-Id: I9071648c2e60eb89d0dc8f08aed793167b42a365
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
On Linux (Ubuntu 20.04) Qt Creator would use /usr/bin/g++ as
compiler for C++. CMake would pick /usr/bin/c++ as C++ compiler.
Both of them are symlinks to /usr/bin/x86_64-linux-gnu-g++-9
There is no need to create imported kits for something which
is the same compiler.
Fixes: QTCREATORBUG-25069
Change-Id: I90e0f7b1977ace3f7995ce09f4b3fcfa64d02b72
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
This way Qt Creator won't be creating imported kits on every import.
On Windows the language "RC" is not part of the kit languages and
would always discard valid matching kits.
Fixes: QTCREATORBUG-25069
Change-Id: Ib4ec323ebf514c82e5036f7d0123100a75f3ea10
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
We need to check canonical paths with canonical paths.
Otherwise we get a mismatch when using e.g. a linked directory for the
source path on the command line and then try to import the build in Qt
Creator.
Change-Id: I153be74b6cfdf5070e023780604ce64c92df0e6d
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
(cherry picked from commit 430a33dcd9)
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Make import of build directories using Qt 6 work. This assumes that
Qt 6 will use the same layout as Qt 5 and that there is qmake (which
is assumed everywhere in Creator right now).
Change-Id: I37194b186127befb3df32ebacf86c032c71ef18a
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The BuildDirManager was used to switch between different
BuildDirReaders. Now that only the FileApiReader is left, that
infrastructure is no longer needed.
Change-Id: I2d339a3407bb633cff6a8f7502b7b09094f63fef
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Keep internals internal, remove some unnecessary includes, add
some that should have been there.
This reduces the number of files that get rebuild when working
on CMake internals from over 1000 to about 200.
This patch also moves some code around that ended up being
in the wrong file.
Change-Id: Icd7366ac760dc85031040720418fbb16336dce9b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The QObject was not heavily used. Object name was for debugging only,
translation context can be taken from the corresponding BuildConfiguration
objects, the qobject_casts in the three big importers are replaced by
dynamic_cast, which is good enough in that context.
Take the opportunity to re-use translations from base BuildConfiguration
for the common cases and sprinkle in some 'final'.
Change-Id: I8e9727c98c6e943cb333556861c24e701c2bdf45
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... and use it in ToolChainFactory::detectForImport() overloads.
Change-Id: I107b9d5e185580b8fbef4c6e0233fdae5d253506
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
More in line with QFileInfo terminonlogy which appears to be
best-of-breed within Qt.
Change-Id: I1d051ff1c8363ebd4ee56376451df45216c4c9ab
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The name "KitInformation" does not properly convey the fact that it
represents a certain *aspect* of a kit. The same goes for
"KitConfigWidget", which in addition was inconsistent with
"KitInformation".
We now use "KitAspect" and "KitAspectWidget".
Change-Id: I9804ee4cedc4d61fad533ea1dd4e4720e67fde97
Reviewed-by: hjk <hjk@qt.io>
In both cases the created lists contain at most one item, no need to check
for duplicates.
Change-Id: Ibd2cb100d4c4199e65ffc62678e255c8ab41b11c
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... to pass it around as real values, avoiding, among others,
the need of occasional explicit deletion.
The formerly extra members of the derived stuff are handled via
an extra variant (for data) and via a functor in the build
configuration factory.
The change is mechanical.
Change-Id: I19ca4e0c5f0a5b196fc16dfb98bb005dc679f855
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
... to BuildConfigurationFactory. It hasn't been an Interface for a
while and the new name matches Run- and DeployConfigurationFactory
Change-Id: I923c6a27e18a99628251b69e0270e910836e7b2a
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Instead, set the default level of all logs to QtWarningMsg.
The call to setFilterRules overrides the user preferences in qtlogging.ini.
Change-Id: Id5f6cd550d14ff7f45ae04c5d3110e0bafb0f072
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: hjk <hjk@qt.io>
This builds on top of 08677c0b01 and
fixes one more code path to go through a common entry/exit point.
Change-Id: I1d00fa9242f247028e5d3b0ef3b5fe1d3f4cb03d
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Compare the CMAKE_HOME_DIRECTORY to the canonical project paths during
cmake project import. CMake makes sure to store the canonical path
there.
Change-Id: I4ae3ad1f8fab66a50ba98d4266c78cdb4d21f2ea
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
