Prevent non-portable dir delimiters from getting into a FilePath.
Change-Id: I78e4a98e03ffe95e3cef70c9c499af28fa33c25c
Reviewed-by: <christiaan.janssen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Some places where ghs-specific checks were done, were not modified to
do the same for ghs-arm.
Change-Id: I484f98209188e4c160a13248ca3c3f046b342b22
Reviewed-by: <christiaan.janssen@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Using Ninja not all modified files will be compiled in an incremental
build.
Fixes: UL-4247
Change-Id: I0bdb1e611e54ea6674ccae4d23391ac86f0960b8
Reviewed-by: <christiaan.janssen@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Currently unused, will be useful to detect toolchains in docker
containers.
Change-Id: I0fd7643969ab02c05839332a436147ffb242635d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Saves some code on the user side.
Change-Id: I32cd220b6e533f5497a1865f9c34ab9db4cfda79
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Enables re-using existing functionality.
The "Make mutable" functionality is still oddly placed. I doubt people
find and use it actively.
Change-Id: Ic6aae17e3a7df093f0f5f234f1e6e1afc196a087
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Kits are marked as 'manual', so that user has individual control of each one.
'Remove' button replaced with 'Update' button for manual update.
Task-number: QTCREATORBUG-25259
Change-Id: Iadf5f2da3ef7bee7fb051516ffda7fcefe8b56d8
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
QUL does not have separate QML import paths, but (re-)uses the include
paths for this purpose. Support this behavior by adding all include
paths to the QML import paths before handing the project information off
to the QML code model.
Change-Id: Ic2e39ab69ac27776f5070b7b8b7c66d53a83210b
Reviewed-by: <christiaan.janssen@qt.io>
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@qt.io>
Although QUL has merged the QML import paths and the include paths, the
convention for C/C++ is to have the headers for a project under a
subdirectory of the include path, and do imports relative to the include
path. For example:
#include <qul/SomeHeader.h>
The QML code model doesn't know about this convention, so for the kit
has to supply an extra QML import path for this case.
Change-Id: I82d4375dd8a1f510180f81b011a715dee8c10d60
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Detecting the presence of Jom, setting CMAKE_MAKE_PROGRAM to it and
choosing "NMake Makefiles JOM" as CMake generator was implemented in a
time where the Qt SDK did not yet ship ninja.
By now, ninja is shipped and it *should* be automatically installed as
dependency of Qt for MCUs. Qt Creator will by default prefer ninja as
generator/buildtool if it is installed.
Task-number: QTMCU-18
Change-Id: Ia83ac3a454b90bb5b5b69ddefb3fbb8f23fa15c9
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: <christiaan.janssen@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Instead of having a hard-coded list of .qch file names to register,
register all .qch files that are present in the Qt for MCUs SDK's docs/
directory.
Turning docs registration into a self-maintaining feature.
Fixes: QTCREATORBUG-25043
Change-Id: Idc7afb78b256bcbb3e8cd7f80fab6a356eb47aa3
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Yoann Lopes <yoann.lopes@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
We should never actually write default values into the settings, because
- if the default value changes in a later Qt Creator version, the new
default should automatically take effect if the user didn't change the
value
- it senselessly grows the settings file
Add a QtcSettings class that extends QSettings by a
"setValueWithDefault" method, which does not write default values to the
settings, and actually removes the settingskey if the user switches back
to the default.
Use it at the places where we already do this manually.
Task-number: QTCREATORBUG-24762
Change-Id: Ia76414cb21e8521f3aeed1e37b43ae4fb3393ea3
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
No implicit casts from QString to QFileInfo anymore, and a few more
QChar(int) fixes.
Task-number: QTCREATORBUG-24098
Change-Id: I3326fc0701a9259c7bdd2d8c3025de0a4774f8aa
Reviewed-by: hjk <hjk@qt.io>
- added IAR toolchain factory similar to ARM GCC one
- extended kitName with used compiler name
- added Unsupported toolchain type to fix crash after creating kit with not
recognized toolchainID
Fixes: QTCREATORBUG-24898
Change-Id: I28b8376ca4bc88d3d75e17bd242ac49f0ee09845
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: <christiaan.janssen@qt.io>
Starting from Qul 1.5 json kit file will be shipped for desktop platform.
This change is backward compatible with previous Qul version - if no
desktop specific json file is found a legacy code is executed.
This change removes "desktop" toolchain, instead "msvc" and "gcc"
toolchains are introduced.
Additional parameter was introduced to the josn kit file: "platformName"
which enables using different strings in kit name and in QUL_PLATFORM
cmake variable.
Change-Id: Ie0a212aaad47a8033e9a81467f60a23c2bc19a51
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
The qul libraries for the Desktop Backend are statically linked against
Qt on Windows. Also, the qul host tools are shipped with the Qt runtime
libraries (on Windows).
Not so on Linux, so a Qt version is required, there.
Change-Id: Id49ed2ef01926abc71291751eae03263317a56d4
Reviewed-by: hjk <hjk@qt.io>
FreeRTOS backend is now a separate platform and requires dedicated json
kit file. Starting form Qul 1.4 there is no option to produce BareMetal
and FreeRTOS kits out of one json file.
This change is backward compatible with Qul 1.3.
Change-Id: Ic50b566a7f1a01fad4b00c07e723dfe1343fc2b0
Reviewed-by: Alessandro Portale <alessandro.portale@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>
So far, one Qt Creator version supported exactly one Qt for MCUs
version, mainly because of incompatibilities in-between Qt for MCUs
versions.
The compatibility of 1.2 with 1.3 and further is now deemed stable
enough to loosen the version checking.
This change replaces the exact versions comparison (between Qt for MCUs
SDK version and what Qt Creator supports) to a minimum version check of
what Qt Creator supports.
One limitation that remains is that you can only have one kit per target,
across the supported Qt for MCUs versions. To mend this, UI changes are
required (in a separate commit).
Workaround for now: If you want e.g. Desktop Kits for different Qt for
MCUs versions at the same time, you need to work with kit clones.
Task-number: QTCREATORBUG-24293
Change-Id: Ifd31cd2eadbc1d7fa02415e1928d0047cf007f7c
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Qt for MCUs 1.3 ships the board/MCU SDKs, and also adds the subdir to
the FreeRTOS component inside the board/MCU SDKs as "boardSdkSubDir" to
the .json files (see: UL-2760).
Task: Qt Creator needs to lookup that "boardSdkSubDir" value and use it
to construct a default path for the FreeRTOS path.
Task-number: QTCREATORBUG-24300
Change-Id: Ie3c8186b76443d5fe3640226ea61aa8b14779d54
Reviewed-by: Rainer Keller <Rainer.Keller@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
