Since we also license under GPL-3.0 WITH Qt-GPL-exception-1.0,
this applies only to a hypothetical newer version of GPL, that doesn't
exist yet. If such a version emerges, we can still decide to relicense...
While at it, replace (deprecated) GPL-3.0 with more explicit GPL-3.0-only
Change was done by running
find . -type f -exec perl -pi -e "s/LicenseRef-Qt-Commercial OR GPL-3.0\+ OR GPL-3.0 WITH Qt-GPL-exception-1.0/LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0/g" {} \;
Change-Id: I5097e6ce8d10233993ee30d7e25120e2659eb10b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Proliferates FilePath use a bit further. Actual changes to the
individual importers are left for further patches.
Change-Id: Ie7c6b2e3f4ac7d0eca6d2f56d30fb23354bb404b
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
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>
The commit a71d725e46 which fixed issues
on ARM Macs also removed logic for CONFIG+=<arch> arguments to qmake,
which was removed from qmake in Qt 5.6 (since PPC and 32bit Macs are no
longer supported or relevant, qbase f58e95f098c8d78a5f2db7729606126fe093cbdf).
The commit only removed part of the logic though, leading to the
Makefile parser and the qmake step disagreeing on the architecture of
the last qmake run, leading to the qmake step being executed again.
Remove the whole architecture detection and matching logic from
everywhere, which only did anything meaningful on macOS, and is not
needed there anymore either.
Fixes: QTCREATORBUG-26212
Change-Id: Ib60ebca1143296194454a63992ab90a97fdb56b6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@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>
... when determining whether to re-run qmake.
We need to look at the effective arguments, not the user arguments.
Of course, the whole approach is still a shaky heuristic, but it should
be more correct now than it was before.
Fixes: QTCREATORBUG-24538
Change-Id: I763f8095becacde0f9549890161b8a47c6344b6b
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Special accessors to the repeatedly used C and C++ cases to denoise
and slim down user code. Plus some code cosmetics nearby.
Change-Id: Iba4662bd4731d8c4256e658529f39d5c995691ce
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@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>
For some reason, Q_UNUSED includes already a semicolon, adding one
on the user side creates an additional empty statement.
Change-Id: I9c5e8fac381345a60792cb75e2938fd53958d3b0
Reviewed-by: Christian Stenger <christian.stenger@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>
... and BaseQtVersion, and QmakeBuildConfiguration.
Change-Id: Iac5f768b80a7f8c2ea9a37d099b285d5793270db
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Even if this is part of a directory name it is naturally closer to a
"string" id than a file path.
Change-Id: If66f930526744379ce86e2b18bd9eac7fabfe773
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
If the user explicitly sets the mkspec for a kit, we should remember
that, even if it happens to be the (current) default mkspec of the kit.
Fixes: QTCREATORBUG-16205
Change-Id: I9ee047bdaecce1aae7d0a8e4dfc2a0a25b6be744
Reviewed-by: hjk <hjk@qt.io>
The code simply picked one matching toolchain and set it on the
temporary kit, ignoring the fact that we have pairs of toolchains (C and
C++). So the second one was set to some random value and typically did
not match the first one, resulting in a broken Kit.
We now collect both types of toolchains.
Fixes: QTCREATORBUG-18153
Fixes: QTCREATORBUG-19423
Change-Id: I348e5467f30d449cc344946ec7e87d4ca5ddfbd1
Reviewed-by: Christian Stenger <christian.stenger@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>
Allow to provide a Predicate to ToolChainManager::toolChains and
add a ToolChainManager::toolChain method.
Change-Id: I0849f6fa67ffd8d5c6cfe4253cb0a326e1b023fa
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Split up the import method into several smaller methods. Call these
from ProjectImporter::import, which now contains the build system
independent parts, moving all the build system dependent code into
the smaller methods.
This will allow to reuse logic for cmake project import.
Change-Id: Idcd1d1daaab18ebcc581cc5aff3f20c7757c639b
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
That way the code can be reused in other importers later.
Change-Id: I6318f9c959b73b2af2692408b918eb1fab715137
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Introduce a base class for importing Qt projects. This class handles
the handling of temporary Qt versions.
Use this in the QmakeProjectImporter.
Change-Id: I2e540f9bb75d607a68d1277db68243b04eee168f
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
This makes clear that the ABI encompasses all Darwin platforms (macOS,
iOS, tvOS, watchOS) in the wake of the OS X to macOS rename, and would
have been more technically correct anyways since ABIs are far below the
"macOS" parts of our favorite desktop Unix operating system.
Change-Id: I16d1477f44ffe70e5d8cddd67199a1602ba6fd97
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
BREAKS BACKWARD COMPATIBILITY OF TOOLCHAIN SETTINGS!
* Convert old ToolChainKitInformation to new version
* Store several toolchains in one kit (one per language)
Change-Id: Ia59a2ad067c57971ec34ce9b2e43758344443755
Reviewed-by: Tim Jenssen <tim.jenssen@theqtcompany.com>
