It's conceptionally const, and would be useful to use as such, but
the current implementations often modifie mutable state.
To ease the transition pain, rename the previous non-const version to
addToLayoutImpl() and call it after const_cast'ing.
Change-Id: Ic8ca38e40f5df69c3d11121f96ea37648cf4feb7
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
This puts the implementation introduced in acf1ecb47f into use, after
significant simplifications in the class hierarchy. CRTP is not used
anymore, and the new tag based dispatch is also used for Layout::addItem,
effectively reducing the number of different code paths.
The Lua based settings access is disabled for now.
Change-Id: Idb6d1a25675378757c5267bdb630bcd4c1f52d34
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Rename process.h back to qtcprocess.h
MSVC's "threads" standard header includes <process.h>, and that ends up
including our process.h from Utils.
There already was a hacky workaround in place for a similar issue with
MINGW, but that doesn't work with MSVC because that doesn't have
Simply use a name that doesn't conflict.
Change-Id: I1159cd2096b4f2dbc4a1728d0131dd6edd30ebd3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
It's the "persisted" form of the content of the original aspect's data,
calling it 'aspect' already confused me a few times.
Change-Id: I88a6f76f0ca39d3d36dde9b84287032ceecf7033
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Avoid using readAllStandard{Output,Error} mutable methods if possible.
Use non-mutable methods when we are not connected to
readyReadStandard{Output,Error} signals.
Change-Id: I2e830e571b9eab2177fd856bbe06dfc5137d9c01
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
WebBrowserSelectionAspect is not too far off from a normal
SelectionAspect, and may be one later.
Change-Id: I4d9d3a77244fe3f30f29746e67f5420ae9c6c3f0
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
No real benefit in this particular case, but the general pattern now.
Change-Id: Ia06d3221a2ccd4b7ab429f6e045c11fffffe99ad
Reviewed-by: Alessandro Portale <alessandro.portale@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>
This was a alias for .stringAppended(), but can be used too easily
when .pathAppended() is meant.
Change-Id: Ia3b64d39828d4074b43d87c923ce3a6a87038948
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
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>
Runnable functionality is nowadays mostly accessed more directly
in QtcProcess and its setup functions.
Change-Id: I2a2b5433aef1d464dc58d5a35069376dee051d57
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
The aspects are now responsible for defining what data needs
to be copied and also to provide a suitable interface (kind
of source-compatible to direct use) for access.
The important change here is that RunControl::aspect(...) doesn't
need to access RunControl::runConfiguration() in fully aspectified
RunConfigurations anymore. In not-fully aspectified the runConfig
access is moved to the user code to make the problem visible there.
Long term, aspectification should be finished.
As an additional benefit, the resolving of macros etc can
now be done at the correct time.
Change-Id: I690d9f8f696ce9b4efd42082ba3f81b514efcb77
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
emsdk's emrun now requires additional PATH entries in order to detect a
web browser location. At least on Windows.
Therefore, as a fix, use the build configuration environment instead of
an empty one for the emsdk call.
Fixes: QTCREATORBUG-27239
Change-Id: Ibe256265bd70f39693594f739403c415108fd981
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Use device set inside passed runnable instead.
Grep for all usages of RunControl::start().
If passed device wasn't nullptr, set this device
inside passed runnable. Otherwise ensure that
passed runnable contains device set to nullptr.
Change-Id: I06fd42a16246fa9fedd81eeb47481a217f887cb0
Reviewed-by: hjk <hjk@qt.io>
This adds a "Default Browser" entry to the browser selection combobox in
WebAssembly' run configuration. Choosing that omits the "--browser"
parameter and let's emrun determine which browser to launch (should by
the system default browser).
In order to implement that, the combobox items now got user data in
addition to have display data. The parsing of emrun's output was
extended to retrieve the long form of a browser name as display data:
"Mozilla Firefox 96.0.0.8041" instead of just "firefox".
The parsing of emrun's outout received a dedicated plugin test.
Turning the result in parseEmrunOutput() non-static fixed
QTCREATORBUG-26562
Fixes: QTCREATORBUG-25028
Fixes: QTCREATORBUG-26559
Change-Id: I18891b88b063903d1a9eeb88a6c906e596e561c1
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
A recent fix for launching CMake-based projects (where target name
differs from project name) broke launching of any qmake-based project.
The reason for the failure is that the code uses to the buildKey in
order to determine the html file name. CMakeProjectManager holds a
buildKey that corresponts to the target name (which is the right base
name for the html file), but qmake holds the project file path as
buildKey.
This change causes the targetFilePath to be used to determine the html
filee name. It works with CMake and qmake.
Amends: b1db3d2506
Fixes: QTCREATORBUG-26849
Change-Id: Ifaa8a279317d7fdb54ceea8198a374a317d9c2d7
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Insipred by a similar fix in McuSupport, it became now clear to me how
to get the target name (aka buildkey) for a runconfiguration.
The hack of searching for .html files can be removed.
At the same time, remove the very detailed update connections, and just
update on Target::buildSystemUpdated.
Amends: dd1882b817
Task-number: QTCREATORBUG-26562
Change-Id: Ic07b36a1e618d6cc2b6f2ee50b4170170f707632
Reviewed-by: hjk <hjk@qt.io>
The new QtQuick application wizard for Qt 6.2-based applications now
uses different names for the project and for the main target.
The WebAssembly plugin cannot construct the html file name for launching
like <projectname>.html, anymore. It instead would need to use
<targetname>.html for that.
The author of this patch did not manage to programmatically retrieve the
target name or buildkey. So, as a hack, we simply chose the first html
file that we find in the build directory.
Fixes: QTCREATORBUG-26562
Change-Id: I7e929fe265a15501c7275e2c76b7f5fa4ed1e6b5
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
From now on do on Linux and macOS what was already done on Windows in
order to launch a WebAssembly program: Directly call the emrun.py python
script instead of indirectly via the wrapper shell script.
The wrapper was too fragile. Also, this change consolidates the code
paths on the three host platforms a bit.
Fixes: QTCREATORBUG-25905
Fixes: QTCREATORBUG-26189
Change-Id: If79567e4dc688de460b38daa479becb53d3c5f03
Reviewed-by: Juha Vuolle <juha.vuolle@insta.fi>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This affects Windows only. Instead of searching python.exe in the Path,
use the executable name which is stored in the "EMSDK_PYTHON"
environment variable (which is set by emsdk_env).
emsdk_env also prepends entries to Path, but not the one pointing to the
emsdk-shipped python interpreter. I believe that earlier versions of
emsdk_env used to add the python location to Path, else this is an old
bug.
Fixes: QTCREATORBUG-25897
Change-Id: I9b5bc43f865d19a862f8c6cd45105be54286a549
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Eike Ziller <eike.ziller@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>
In most cases they are used directly, so there's not much Base* in that.
Added the old name as alias as porting help for a while.
Change-Id: I494a8a560b8996bcf74915ea3570b504df6a6b4c
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
The coreplugin/id.h header is kept for downstream for now.
Change-Id: I8c44590f7b988b3770ecdc177c40783e12353e66
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
With Emscripten SDK 1.39.x, emrun quits and shuts down the web server
before the complete WebAssembly application can be fetched by the
browser.
Adding "--serve_after_close" to the emrun call restores the original
behavior. That parameter is accepted by previous Emscripten SDK versions
and seems to not change how it used behave in earlier versions.
Task-number: QTCREATORBUG-24072
Change-Id: Ie43604d42eb9c5a7cccd09fdf1c33391dc31098d
Reviewed-by: hjk <hjk@qt.io>
This spares us the typical r = runnable(); modify(r); setRunnable(r)
roundtrip and the m_runnable storage that might or might not
be the same as runControl->runnable. Similar for m_device.
Change-Id: I8300260dd8dd7cd395e40bcd3d2ae45089085008
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This is what the consuming code expects in most cases.
Change-Id: I135592039e28b994996186f627215ab1d2f8d6dc
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This combines two of the previous three paths to create run workers,
and refers to RunConfigurations by id, not by type where possible
to decrease coupling between the classes.
Only allow "type of run configuration" and "type of device"
as the only possible kind of restriction and require a uniform
RunWorker constructor signature.
Adapt user code to fit that pattern.
Change-Id: I5a6d49c9a144785fd0235d7586f244b56f67b366
Reviewed-by: Christian Stenger <christian.stenger@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>
