The prior investigation concluded "the dependency structure permits it" but stopped before any compiler ran. I ran one.
NetCDF is the only thing in the way
All 58 files in src/, with em++ -std=c++11 -fsyntax-only under docker.io/emscripten/emsdk:
|
Count |
| Compile unmodified |
10 |
| Fail |
48 |
| Distinct first-error messages across all 48 failures |
1 |
Every failure is 'netcdf' file not found. No second problem behind it — no missing POSIX header, no unsupported construct, no toolchain incompatibility. The ten that compile are the ones that never reach DataBroker.h:
BurningMap FFEvent FFPoint FFVector FireNodeData
ParallelData ParallelException SimulationParameters Simulator TimeTable
#include <netcdf> appears in exactly one place, src/DataBroker.h:25, and the using namespace netCDF there drags it into everything transitively.
Everything else checks out
- MPI is fully behind
#ifdef MPI_COUPLING; #include <mpi.h> (CLibForeFire.cpp:15) is inside the guard, and the flag is already off for wheel builds.
- The HTTP server is three references:
Command.h:25, Command.h:249, Command.cpp:3422.
popen is one block, Command::systemExec.
termios appears only in app/forefire/AdvancedLineEditor.cpp, which a WASM build would not compile.
One portability finding
em++ flags seven -Wvla-cxx-extension, e.g. ArrayDataLayer.h:275:
Variable-length arrays are C99, never adopted by C++; GCC and Clang accept them as an extension, MSVC does not. Not a WASM blocker, but a latent portability problem and a stack-overflow risk if those dimensions are ever large. Worth fixing independently.
What remains unknown
- Does it link and run?
-fsyntax-only only. Codegen, linking and execution untested.
- Binary size. Unmeasured; ~34k lines with heavy templating in the layer classes.
- Threads. Emscripten pthreads need
SharedArrayBuffer plus COOP/COEP headers, which conflicts with the "just a static page" appeal. Single-threaded is fine for a demo, but the browser build and the free-threading work do not compose.
Why it is worth the weekend
The demo becomes a static page — no server, and the listenHTTP exposure stops being a deployment concern. tools/htdocs/ is already 2811 lines of working Leaflet UI, and data would come in as JS typed arrays through the same interface #168 documents for numpy. Adjacent payoff: the same FF_NO_NETCDF guard enables a slim wheel that drops the entire NetCDF/HDF5 group.
Next step: guard #include <netcdf>, the using namespace netCDF, the six NcVar declarations in DataBroker.h, the two implementation blocks in DataBroker.cpp, and loadArrivalTimeNC/saveArrivalTimeNC in FireDomain.cpp behind FF_NO_NETCDF. Then re-run the sweep and see what the second error is, if there is one.
Drafted by Claude Opus 5 from a codebase audit. Reviewed by a maintainer before filing.
EDIT: rewrote for human readability.
The prior investigation concluded "the dependency structure permits it" but stopped before any compiler ran. I ran one.
NetCDF is the only thing in the way
All 58 files in
src/, withem++ -std=c++11 -fsyntax-onlyunderdocker.io/emscripten/emsdk:Every failure is
'netcdf' file not found. No second problem behind it — no missing POSIX header, no unsupported construct, no toolchain incompatibility. The ten that compile are the ones that never reachDataBroker.h:#include <netcdf>appears in exactly one place,src/DataBroker.h:25, and theusing namespace netCDFthere drags it into everything transitively.Everything else checks out
#ifdef MPI_COUPLING;#include <mpi.h>(CLibForeFire.cpp:15) is inside the guard, and the flag is already off for wheel builds.Command.h:25,Command.h:249,Command.cpp:3422.popenis one block,Command::systemExec.termiosappears only inapp/forefire/AdvancedLineEditor.cpp, which a WASM build would not compile.One portability finding
em++flags seven-Wvla-cxx-extension, e.g.ArrayDataLayer.h:275:Variable-length arrays are C99, never adopted by C++; GCC and Clang accept them as an extension, MSVC does not. Not a WASM blocker, but a latent portability problem and a stack-overflow risk if those dimensions are ever large. Worth fixing independently.
What remains unknown
-fsyntax-onlyonly. Codegen, linking and execution untested.SharedArrayBufferplus COOP/COEP headers, which conflicts with the "just a static page" appeal. Single-threaded is fine for a demo, but the browser build and the free-threading work do not compose.Why it is worth the weekend
The demo becomes a static page — no server, and the
listenHTTPexposure stops being a deployment concern.tools/htdocs/is already 2811 lines of working Leaflet UI, and data would come in as JS typed arrays through the same interface #168 documents for numpy. Adjacent payoff: the sameFF_NO_NETCDFguard enables a slim wheel that drops the entire NetCDF/HDF5 group.Next step: guard
#include <netcdf>, theusing namespace netCDF, the sixNcVardeclarations inDataBroker.h, the two implementation blocks inDataBroker.cpp, andloadArrivalTimeNC/saveArrivalTimeNCinFireDomain.cppbehindFF_NO_NETCDF. Then re-run the sweep and see what the second error is, if there is one.Drafted by Claude Opus 5 from a codebase audit. Reviewed by a maintainer before filing.
EDIT: rewrote for human readability.