Windows only: When toolchains get restored on startup,
WebAssemblyToolChain would try to add MinGW to an environment. That
env is used for querying the compiler version. In order to find MinGW,
the MinGW toolchain is queried from ToolChainManager. But since the
ToolChainManager is not yet loaded at this moment, we get a QTC_CHEK
assert from ToolChainManager::toolChain.
This change prevents querying the ToolChainManager before it is loaded.
The compiler version can successfully be determined without MinGW in
path.
Whether we really need to query compiler versions that early is another
question outside the scope of this change.
Change-Id: I46edbb80edc58d7465e90e99f7f8381708f704a1
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Includes delaying construction until its first actual use.
Change-Id: Ide0f7a12250c2597f45993d6ef0fb604c974a763
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
... explicitly only for the Desktop device. This was implicitly done in
some cases by assuming 'no device' == 'desktop'. Make that explicit now.
Change-Id: I2ce86702a9b5b795fb4832301a11a8c8b40e77ea
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
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>
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>
Also, make some functions const and use an alias for QList<ToolChain *>.
Change-Id: I6a1cbcb79bfaa9d252c4b69e00aa93e5d0dabe2f
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Makes it a bit clearer that there's no magic path use or similar
beyond this point.
Change-Id: I86c06850d16bf777db05ad23b540d8096926c059
Reviewed-by: David Schulz <david.schulz@qt.io>
It's effectively the mirrored version of onDevice() with an
equally odd name which is a bit more straightforward to use
in some cases.
Change-Id: I0cfedeb58871a857c93144e2a0d734bad1bcd887
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
To start using the docker bits the emsdk location has to
be specified manually in the path selector as
docker://<id-of-image>/<path/to/emsdk>
Change-Id: I70c6e7a334762953c3931105b7f697c608523159
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>
Qt Creator's ability to register Emscripten toolchains depended on an
SDK being activated "globally", and on the presence of the ~/.emscripten
file. Qt Creator would parse that file in order to determine the
location of the compiler and the necessary environment variables that
have to be set.
As of recently, the Emscripten SDK does neither activate gobally
anymore, nor is the ~/.emscripten generated. This change here addresses
the new situation in a couple of ways:
- Instead of trying to silently detect everything, add a UI
(IOptionsPageWidget) that lets the user select the Emscripten SDK root.
- Instead of parsing the ~/.emscripten file, parse the output of the
emsdk_env tool to determine the toolchain environment
(ToolChain::addToEnvironment). The parsing is cached. A test for the
parsing is included.
- Instead of registering the underlying clang as compiler, register the
emcc/em++ wrapper scripts, which are (also as of recently) compatible
with Qt Creator's way of determining gcc's predefined macros and built-
in header paths.
One Emscripten SDK is registered globally in Qt Creator. When changing
that, the previous Emscripten toolchains are removed, the new ones are
registered and the kit are "fixed" to use those.
On startup, an InfoBar entry is shown if Qt for Webassembly kits exist
and no Emscripten toolchains are present. That's the case for first-time
use after installing Qt for Webassembly via Qt SDK installer. The
InfoBar entry opens up the IOptionsPageWidget.
Qt 5.15.0 for WebAssembly and Emscripten SDK 1.39.0 are the minimum
supported versions. The new UI will show warnings accordingly.
Task-number: QTCREATORBUG-24811
Fixes: QTCREATORBUG-24822
Fixes: QTCREATORBUG-24814
Fixes: QTCREATORBUG-23741
Fixes: QTCREATORBUG-23561
Fixes: QTCREATORBUG-23160
Fixes: QTCREATORBUG-23126
Change-Id: I017c61586b17e815bb20a90e3f305a6bf705da36
Reviewed-by: hjk <hjk@qt.io>
As collateral damage, use a capital C in KeilToolchain*.
Change-Id: If9d64de2108366546683144975d975d9d1727712
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The build system of Qt for WebAssembly on Windows requires MinGW in the
path. If a MinGW toolchain is registeded (e.g. via Sdk installer),
append it to the path.
Change-Id: I5c33cb5c4df636be99f815e307806efc07e18a11
Reviewed-by: hjk <hjk@qt.io>
This change adds WebAssembly support in the shape of a plugin.
- Auto-detection of the emsdk toolchain
- Handling of "asmjs-unknown-emscripten" Abi
- Binary detection of WebAssembly libraries
- Auto-creation of a "WebAssembly runtime" device (with icon)
- Runconfiguration that launches the application via the "emrun"
tool which spawns a local web server and runs the application on
the chosen web browser.
Limitations:
- So far only tested on Windows/MinGW and Linux
- Not yet tested with Qt WebAssembly installation form the installer
Only tested with self-built Qt and manually added kit
- The attempt to launch an application via emrun, while a previous
application is still running, will fail. The reason is that the
web servers spawned by emrun listen to the same default port but
serve only the content of one application.
Possible solutions: We could either spawn the different web servers
with different ports, or we could use one single web server instance
which serves the whole default project location (home directory).
Task-number: QTCREATORBUG-21068
Task-number: QTCREATORBUG-22249
Change-Id: I1a16fbe52382d45c37e9bc624a943a6ca475fa09
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
