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>
The download icon might suggest that clicking that button causes an
automated download/installation. Since we have similar automation in the
Android settings, that could be misleading.
Change-Id: Ia1e4f1cfe15f79daf090546ee7c991f93b23fd13
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
This change adds a "reset" button to the path choosers. Pressing it
sets the path to the default path.
The default path is now overwritable by the system settings value (if
present). This way, there is only one and only default path, which
allows us to again simplify McuPackage::writeToSettings().
Task-number: QTCREATORBUG-23860
Change-Id: I192663f3487250b9eba4773d2510abf3f9e66127
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The plugin wants to only store settings if they differ from the defaults
(e.g. a path was edited by the user).
The original attempt failed. If the user changed the path, stored it,
and then changed the path back to the default, the last change was not
stored.
Therefore, this change actually removes the settings entry if it equals
either the default or the install settings value.
Task-number: QTCREATORBUG-24048
Change-Id: I6ab11f276ae270bb8bbf50ad6d2bc7ea3dba2d7b
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
- Bump supported version from 1.1 to 1.2
- Look in Qul_DIR/kits for boards json files (UL-2390)
- Remove "pragma main;" from app template main qml (UL-1708)
- Add a main.cpp for BareMetal and FreeRTOS each (QTCREATORBUG-24063)
- Removed ambiguous armgcc download link (QTCREATORBUG-24052)
Task-number: UL-1708
Task-number: UL-2390
Task-number: QTCREATORBUG-24063
Task-number: QTCREATORBUG-24052
Task-number: QTCREATORBUG-24079
Change-Id: Ieb3d0c22b9099b12f91096b5a90c6e84698be788
Reviewed-by: Christian Kamm <mail@ckamm.de>
... Replace the current hard-coded list of supported (non-Desktop)
targets.
Task-number: UL-2012
Change-Id: I65851d11eea9f62635d56c42788caeae8a77a4f3
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Besides Baremetal, Qt for MCUs also supports FreeRTOS for a few targets.
This change:
- shows the FreeRTOS source path chooser
- set the FreeRTOS source path as kit environment variable
- sets OS=FreeRTOS in the kit CMake configuration and kit meta data
Task-number: QTCREATORBUG-23938
Change-Id: I69cbd4f9b6b4a842788a8dad57905ef517b8b1d5
Reviewed-by: Rainer Keller <Rainer.Keller@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
