Stores the results of emsdk_env and --dumpversion in the settings
database. Also stores the modification time of the ".emscripten" file in
the sdk root folder in order to validate the cached entries.
Change-Id: Iacb907ee6d8cd9f4c14d33a6ad425ec684c66238
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: David Schulz <david.schulz@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>
In order to run emcc 1.39.8 on Ubuntu 20.04., the PATH environment
variable must not be empty, because the emsdk wrapper scripts depend on
it.
Therefore, in WebAssemblyEmSdk::version(), we don't start anymore with a
clean environment bu with the related device environment.
Task-number: QTCREATORBUG-26199
Change-Id: I8b7603ef8126ebaef0fa4ed9e254296623c945e9
Reviewed-by: hjk <hjk@qt.io>
The wrapper scripts of emscripten 1.39.8 (required version for Qt 5.15)
do not actively use the python interpreter which -at least on Windows-
is found under EMSDK_PYTHON.
This change appends the parent path of EMSDK_PYTHON to the environment's
PATH to make wrapper scripts (e.g. emcc.bat) work.
Fixes: QTCREATORBUG-26199
Change-Id: Icbc89f6d930f1c5ac5e4e6ac919383cfdd1b913b
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Similar to QT_RESTRICTED_CAST_FROM_ASCII to avoid the need for
decorations in user code.
At the same time, drop some convenience constructors and functions
in CommandLine and Icon essentially serving the same purpose.
Change-Id: Ida4e5ac19c2da0a4298a97b2a8e1511d56bbb79d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Stenger <christian.stenger@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>
On Windows, we would start with a clean environment just with the emsdk
environment added in order to run "em++.bat -dumpversion".
That fails for some emsdk versions for reasons unknown. Let's reduce OS-
specific special casing and instead use the system environment as basis
everywhere.
Change-Id: I143fe6193528390e17ee0a62936ad03d2c5a109e
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The ':' in "c:\" got confused with the paths list separator ':' on
Linux/Mac.
Let's add a non-Windows specific emsdk_env output to be parsed by the
autotest.
Change-Id: I900e13065237bc0d68eca5582b286177e90cc0af
Reviewed-by: Christian Stenger <christian.stenger@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>
