Skip to content

do not merge: Carry/wasm - #1

Draft
jdsika wants to merge 4 commits into
masterfrom
carry/wasm
Draft

do not merge: Carry/wasm#1
jdsika wants to merge 4 commits into
masterfrom
carry/wasm

Conversation

@jdsika

@jdsika jdsika commented Jul 27, 2026

Copy link
Copy Markdown

CI test for feature branch

jdsika added 4 commits July 27, 2026 08:59
Emscripten defines __unix__ but not __linux__, and is matched by none of
the existing platform branches. All three files below therefore fall
through to their #error fallback, so the library cannot be compiled to
WebAssembly at all:

  - cpp/openScenarioLib/src/common/ExportDefinitions.h
  - cpp/expressionsLib/inc/OscExprExportDefs.h
  - cpp/openScenarioLib/src/loader/FileResourceLocator.cpp

Add an __EMSCRIPTEN__ branch to the two symbol-visibility chains (no
visibility attribute is needed, as for __APPLE__), and accept
__EMSCRIPTEN__ in the POSIX branch of FileResourceLocator, which already
handles Linux and macOS identically and needs no change beyond the guard.

Verified that the preprocessor chains resolve under -D__EMSCRIPTEN__ and
that the existing Windows, Linux and macOS branches are reached exactly
as before.

Signed-off-by: Carlo van Driesten <carlo.van-driesten@vdl.digital>
cpp/externalLibs/Filesystem/filesystem.hpp is a vendored copy of
gulrak/filesystem v1.3.2 (GHC_FILESYSTEM_VERSION 10302L), which predates
that library's Emscripten support. Emscripten defines __unix__ but not
__linux__, and none of the branches in the GHC_OS_DETECTED chain match it,
so the header stops at

  #error "Operating system currently not supported!"

and the library cannot be compiled to WebAssembly.

Map __EMSCRIPTEN__ onto the existing GHC_OS_LINUX branch: Emscripten's
POSIX layer provides everything that branch selects. The new #elif is
unreachable unless __EMSCRIPTEN__ is defined, so no existing platform
changes preprocessor state and no behaviour changes for any current target.

Upstream ghc::filesystem handles Emscripten natively as of v1.5.x (it
defines GHC_OS_WEB), so bumping the vendored copy would remove the need for
this edit. This commit is the minimal alternative to that bump.

Signed-off-by: Carlo van Driesten <carlo.van-driesten@vdl.digital>
XmlScenarioImportLoader::Load(messageLogger, injectedParameters) forwards to the
inner loader's single-argument overload, so the injected parameter map is
dropped before parameter resolution ever sees it. Every embedder that resolves
catalogs loses parameter injection silently — including openScenarioReader,
which reads its -p parameter file, echoes the parameters it found, and then
resolves the scenario as if none had been given, because CheckFile always goes
through ExecuteImportParsingV1_x.

Forward the map to the inner loader. The same line is affected in all four
version loaders (v1_0, v1_1, v1_2, v1_3); the non-import
XmlScenarioLoaderFactory path was already correct, which is why the behaviour
depends on whether catalogs are resolved.

Signed-off-by: Carlo van Driesten <carlo.van-driesten@vdl.digital>
Emscripten's <cfenv> does not define these macros, so EvaluatorListener.cpp
does not compile for a WebAssembly target. Shimming them to 0 makes the
surrounding feclearexcept/fetestexcept calls no-ops, which means
overflow/underflow detection in the expression evaluator is disabled in this
build.

That is a correctness trade-off rather than a portability fix, so it is not
offered upstream as a pull request. It is raised as upstream issue RA-Consulting-GmbH#229
(EvaluatorListener uses FE_OVERFLOW/FE_UNDERFLOW, which Emscripten's <cfenv>
does not provide) and carried here until upstream decides the contract for
targets without an FP-exception environment.

Signed-off-by: Carlo van Driesten <carlo.van-driesten@vdl.digital>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant