Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Task-number: QTBUG-67283
Change-Id: I708fd1f9f2b73d60f57cc3568646929117825813
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
When importing a CMake build, the CMake version that's used in the build
could be registered as "CMake 0.0.0". This is obviously wrong.
Fixes: QTCREATORBUG-26999
Change-Id: I1401106806c4356516e8235a3767d9615e4d428d
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
After parsing the CMake response, we make the configuration variables
table reflect the actual configuration in the build directory. It is one
of our "promises" that we do not break an existing build configuration,
to avoid unexpected rebuilds.
This was not quite true for the "QML debugging and profiling" setting.
When that setting and the actual build directory disagreed, the user
would get a dialog asking for running CMake with additional parameters,
and when running CMake via the button in projects mode or the menu, it
would just change these configuration parameters, potentially leading to
an unexpected complete rebuild of the application.
So, after parsing check if the actual CMake configuration matches our
QML debugging setting, and if not, change the setting to "Leave at
Default", to ensure that we don't mess with the build.
Fix the "Run CMake" button state (in the "Current Configuration") when
changing the QML debugging option, which should become bold, if the
CMake parameters change.
Amends 2577ce8ba1 and fixes the drawback
mentioned there, i.e. setting the build directory of a "Debug" build
configuration to an existing build directory with QML debugging
disabled, will now simply set the QML debugging option to "Leave at
Default" instead of forcing it to "Enabled".
Change-Id: Ie6d4875d59319687d94e44e459ca76038e5813c0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
When configuring a CMake project on the command line, CMake will
(correctly) find and use the compiler from the current developer
directory, usually somewhere in
/Applications/Xcode.app/Contents/Developer
But Qt Creator auto-detects and sets up the compiler /usr/bin/clang(++)
for desktop kits. This leads to a compiler mismatch between kits and the
imported build, and to new kits registered in Qt Creator for the import.
Since /usr/bin/clang(++) is just a thin wrapper that resolves to the
compiler in the current developer directory, resolve that in Qt Creator
with "xcrun -f <command>" too (caching the result), and include that
when comparing toolchains for importing builds.
Fixes: QTCREATORBUG-27591
Change-Id: I301e2a4e267450b488b49d0c32d4ce89001bb5ec
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Get rid of the hardcoded QML Debugging for Debug & RelWithDebInfo from
the project template, because RelWithDebInfo is actually a good
configuration for doing releases (we use it for Qt Creator), and
enabling QML debugging for releases is a bad idea.
Instead enable QML Debugging in Qt Creator for the Debug configuration,
and add a 'Profile' configuration that is 'RelWithDebInfo + QML
Debugging'.
When importing a build, we only set the "QML debugging" option of the
build configuration, if it is enabled in the imported build, even if it
uses CMAKE_BUILD_TYPE=Debug .
One drawback: When not importing a build, but just setting the build
directory of a "Profile" or "Debug" configuration to an existing build,
Qt Creator asks if it should apply "-DCMAKE_CXX_FLAGS=-DQT_QML_DEBUG".
The user can choose not to, but then is asked the next time again, and
it is not obvious that the "QML debugging" option is responsible for
this.
That is somewhat orthogonal to this change though: Even without this
change, if the user changes the QML debugging option from "Leave at
Default" to "Enable", the same happens, and it is also not clear to the
user how to get rid of it. The user might not even have realized that
they changed the option (e.g. on platforms where the mouse wheel cycles
combo box values).
I think the correct solution is to 1. make clearer where the CMake flags
came from in that dialog, 2. allow the user to cancel a build from that
dialog, 3. allow the user to discard these changes (by changing the
setting) from that dialog. But that is for another patch.
Amends 3300182d40
Amends 77fed0b0fd
Change-Id: I95de59473b67c5afd6a53ea7f49838dbaef770d4
Reviewed-by: Artem Sokolovskii <artem.sokolovskii@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
... by direct use of CMakeConfig::fromFile(). It was only duplicating
checks that are done on the user side already.
Change-Id: Iaf5e89c924c2b0a9080db9fe160970bbf6e33154
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
... into a single class.
This makes passing them around as a whole easier, and opens a path
to have "generic" filters in form of a lambda or such.
Change-Id: Ibf644b2fedcf0f1a35258030710afff8f5873f88
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Less conversions cycles at the price of a few more temporary bytes.
Change-Id: Ibda82e02d7b83944f5db38ac7cf75c4bae4f55ec
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
This helps to lower impedance in the using code.
Even though TemporaryDirectory will very likely always stay on the local
host, this is one of the entry points into path related string
manipulation
that we want to base on FilePath nowadays.
Change-Id: I302016b8d65e54df94296659a54a93935d9e4627
Reviewed-by: David Schulz <david.schulz@qt.io>
The previous indirection was useful as long as they were overloads
for QProcessEnvironment and QStringList, but these are gone now.
Change-Id: I5066bd2e72fd06948a5cc7bbac6dda9006db96ed
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Makes run() more similar to what start() looks like.
Also add some asserts to make sure run() and related functions are
only called on SyncronousProcesses, as these are currently the only
ones where this works.
Change-Id: Idee6076c3f40a484db5c17f5bb348698cc83d220
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The potential extensibility was never used, and a similar use case
in QtcProcess (setLowPriority()) used a named setter.
Change-Id: I87d84ea2206995d5069265f8df78f40cf2ba8a36
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
The potential extensibility was never used, and a similar use case
in QtcProcess (setLowPriority()) used a named setter.
Change-Id: I77d84ea2206995d5069265f8df78f40cf2ba8a36
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
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>
