Use different method of emitting Ninja warning

[RReverser]

I find EMCC_USE_NINJA quite useful sometimes, but it's problematic to use in projects that use -Werror, including some tests in the test suite itself as -Wexperimental it uses for warning is subsumed by -Werror and can fail the build:

emcc: error: ninja support is experimental [-Wexperimental] [-Werror]

Could the severity be reduced somehow so that it doesn't fall under -Werror, either by including it in a different category or using a different mechanism for reporting the warning altogether?

[sbc100]

Can you not inject -Wno-experimental ? Its kind of gross but in the worst case you could set EMCC_CFLAGS=-Wno-experimental.

[RReverser]

Its kind of gross but in the worst case you could set EMCC_CFLAGS=-Wno-experimental.

Hm yeah good idea, I could do that, it's just that I ran into this enough times by now that I thought might be worth raising an issue to see if it's worth fixing upstream.

I'll do that for now though, thanks.

[RReverser]

Is Ninja support still considered experimental? I've been using it for a while and would be nice to remove the EMCC_CFLAGS hack if possible. Given that it requires explicit opt-in via special environment variable anyway, seems like a low-risk to unmark it as such?

[sbc100]

Sure, given that its opt-in and that we use it are part of the official build I think we can remove that warning. (What to send a PR?)

In the long run I'd like to add ninja to emsdk and start using it by default!

[RReverser]

After posting the comment I decided to check whether it works on Windows setup too (I've been using it for a long time in WSL) and looks like it doesn't so maybe a bit more extra work is needed.

Getting lots of messages like

ninja: error: build.ninja:39: expected build command name
build c:\users\me\documents\emscripten\cache\build\libc\pthread_self.o: ...
^ near here

It appears it doesn't like Windows paths for some reason? But I never had issues with Ninja on Windows when generated by CMake, maybe worth checking what they do differently, like maybe paths need to be put into quotes or something.

[RReverser]

Checked on a CMake-based project I had around, looks like they 1) convert all \ to / and 2) escape some special chars with $ sign ,e.g.

#############################################
# A missing CMake input file is not an error.

build C$:/Program$ Files/CMake/share/cmake-3.27/Modules/CMakeCCompiler.cmake.in C$:/Program$ Files/CMake/share/cmake-3.27/Modules/CMakeCCompilerABI.c C$:/Program$ Files/CMake/share/cmake-3.27/Modules/CMakeCInformation.cmake C$:/Program$ Files/CMake/share/cmake-3.27/Modules/CMakeCommonLanguageInclude.cmake ...

or just use relative paths where possible, in which case replacing \ to / should be enough

build CMakeFiles/install.util: CUSTOM_COMMAND all

I can probably make a fix.

[RReverser]

Sure, given that its opt-in and that we use it are part of the official build I think we can remove that warning. (What to send a PR?)

Done #20559.