Summary
QtWebSocketBackend unconditionally includes <QSslConfiguration>, takes a
std::optional<QSslConfiguration> constructor parameter, and stores one as a member.
Qt builds configured without SSL define QT_NO_SSL and do not provide that type. The Qt for
WebAssembly build is the common case — TLS is terminated by the browser, so Qt ships no SSL
backend. Against such a Qt the header does not compile.
Reproduction
Build any translation unit including morph/qt/qt_websocket_backend.hpp against a Qt
configured with -no-ssl (or the standard wasm Qt):
fatal error: 'QSslConfiguration' file not found
Why it matters
It's a hard compile failure rather than a degraded feature: the whole Qt backend becomes
unavailable on a target where the WebSocket transport itself works fine. wss:// still works
on that target too — the page's TLS is handled by the browser before Qt sees the socket — so
the only thing genuinely absent is the ability to configure TLS from C++.
Suggested fix
Guard the SSL surface, leaving everything else intact:
#ifndef QT_NO_SSL
# include <QSslConfiguration>
#endif
explicit QtWebSocketBackend(
QUrl serverUrl,
/* ... */
#ifndef QT_NO_SSL
std::optional<QSslConfiguration> tls = std::nullopt,
#endif
Config cfg = Config{});
private:
#ifndef QT_NO_SSL
std::optional<QSslConfiguration> _tls;
#endif
plus the corresponding guards around the .cpp uses.
A note in the class docs that the parameter is absent on SSL-less builds — and why wss://
nonetheless works there — would save the next person the same investigation.
Trade-off worth naming: this makes the constructor signature vary by build configuration.
The alternative — keeping the parameter and ignoring it — isn't available, since the type
doesn't exist. If you'd rather express it as a distinct tlsConfig() setter that simply isn't
declared under QT_NO_SSL, that keeps the constructor stable and I'm happy to do it that way.
Happy to open a PR.
Summary
QtWebSocketBackendunconditionally includes<QSslConfiguration>, takes astd::optional<QSslConfiguration>constructor parameter, and stores one as a member.Qt builds configured without SSL define
QT_NO_SSLand do not provide that type. The Qt forWebAssembly build is the common case — TLS is terminated by the browser, so Qt ships no SSL
backend. Against such a Qt the header does not compile.
Reproduction
Build any translation unit including
morph/qt/qt_websocket_backend.hppagainst a Qtconfigured with
-no-ssl(or the standard wasm Qt):Why it matters
It's a hard compile failure rather than a degraded feature: the whole Qt backend becomes
unavailable on a target where the WebSocket transport itself works fine.
wss://still workson that target too — the page's TLS is handled by the browser before Qt sees the socket — so
the only thing genuinely absent is the ability to configure TLS from C++.
Suggested fix
Guard the SSL surface, leaving everything else intact:
plus the corresponding guards around the
.cppuses.A note in the class docs that the parameter is absent on SSL-less builds — and why
wss://nonetheless works there — would save the next person the same investigation.
Trade-off worth naming: this makes the constructor signature vary by build configuration.
The alternative — keeping the parameter and ignoring it — isn't available, since the type
doesn't exist. If you'd rather express it as a distinct
tlsConfig()setter that simply isn'tdeclared under
QT_NO_SSL, that keeps the constructor stable and I'm happy to do it that way.Happy to open a PR.