Option to suppress errors related to unsupported features

From what I've gathered so far, it seems like unsupported functionality is guarded by emission of preprocessor errors at the point of #including a header that represents such functionality. Maybe there's something I've missed, but this seems somewhat heavy handed and difficult to work around. Presumably in most cases, including a header alone would not cause issues so long as certain symbols are not referenced?

My immediate issue relates to trying to build code for WASI which uses C++20 modules (a niche combo admittedly). Since the standard library module will just include a bunch of system headers, the build fails right away:

In file included from C:\WASM\wasi-sdk-25.0-x86_64-windows\share\wasi-sysroot\share\libc++\v1\std.cppm:52:
In file included from C:\WASM\wasi-sdk-25.0-x86_64-windows\bin\../share/wasi-sysroot/include/wasm32-wasi/c++/v1\csetjmp:37:
C:\WASM\wasi-sdk-25.0-x86_64-windows\bin\../share/wasi-sysroot/include/wasm32-wasi\setjmp.h:13:2: error: Setjmp/longjmp support requires Exception handling support, which is [not yet standardized](https://github.com/WebAssembly/proposals?tab=readme-ov-file#phase-3---implementation-phase-cg--wg). To enable it, compile with `-mllvm -wasm-enable-sjlj` and use an engine that implements the Exception handling proposal.
   13 | #error Setjmp/longjmp support requires Exception handling support, which is [not yet standardized](https://github.com/WebAssembly/proposals?tab=readme-ov-file#phase-3---implementation-phase-cg--wg). To enable it, compile with `-mllvm -wasm-enable-sjlj` and use an engine that implements the Exception handling proposal.
      |  ^
In file included from C:\WASM\wasi-sdk-25.0-x86_64-windows\share\wasi-sysroot\share\libc++\v1\std.cppm:53:
In file included from C:\WASM\wasi-sdk-25.0-x86_64-windows\bin\../share/wasi-sysroot/include/wasm32-wasi/c++/v1\csignal:46:
C:\WASM\wasi-sdk-25.0-x86_64-windows\bin\../share/wasi-sysroot/include/wasm32-wasi\signal.h:2:2: error: "wasm lacks signal support; to enable minimal signal emulation, compile with -D_WASI_EMULATED_SIGNAL and link with -lwasi-emulated-signal"
    2 | #error "wasm lacks signal support; to enable minimal signal emulation, \
      |  ^
2 errors generated.

Is it feasible to allow for these errors to be conditionally disabled via macros (actually it seems for the signals there is a macro, but not for the exceptions), leaving it up to the user to navigate potential linker/runtime issues that could result?

Start by inspecting the unsupported-feature guards in setjmp.h and signal.h, along with the inclusion paths through csetjmp, csignal, and std.cppm. Determine whether conditional suppression can be made consistent without changing the existing opt-in behavior; done would require an agreed macro-based approach and validation that the headers can be included without those preprocessing errors.