set(CMAKE_SYSTEM_NAME WASI) issues on macOS host

[axic]

It is great to have wasi.cmake and we use it in several projects (ethash,evmone), however during integration we have noticed one shortcoming stemming from the set(CMAKE_SYSTEM_NAME WASI) setting.

CMake will try to find Platform/WASI.cmake, but if missing, it will fall back to the host system. This works okay on Linux systems, but fails on macOS as that will add compiler settings only available/valid for macOS targets.

There are two possible fixes I have found:

1. Copy the platform file to CMake
2. Change/override the CMAKE_SYSTEM_NAME to Linux

The downside of option 1 is that it requires change to the installed cmake (copying a new file), while using the toolchain file works without any host changes.

We have decided to override the system name in our files, but I wonder if it would make sense to just change it to Linux in this repository. Any opinions? I can submit a PR if that is there's agreement for this change.

If there's any other options on top of the above, please let me know.

[sbc100]

I think that this can be made to work without installing into the system location.

We already include both wasi.cmake and cmake/Platform/WASI.cmake in this repo, so I think it just a matter of setting up the cmake paths correctly to have it pick up the cmake/Platform/WASI.cmake file correctly.

[sbc100]

(I'm not sure what the exact answer is.. but the existence of cmake/Platform/WASI.cmake is good hint)

[axic]

Hmm, for some reason on our end the platform file was not picked up. Do you have a hint how to set an alternative platform path?

[sbc100]

Looks like its CMAKE_MODULE_PATH.

Looking at the emscripten cmake plugin it looks like the toolchain file injects:
https://github.com/emscripten-core/emscripten/blob/3c0587f94c2b9b0e29ea6a4054a1b8ea9a148f9d/cmake/Modules/Platform/Emscripten.cmake#L77

I wonder if that is pattern we can/should copy?

[axic]

That is a good lead! A quick search in CMake docs shows unfortunately no results for CMAKE_PLATFORM_PATH.

Don't see anything related to platform in the variable list.

Have not tried whether abusing module could help (I doubt it). I have to come back to this tomorrow.

[sbc100]

I think it will look for Platform/WASI.cmake in CMAKE_MODULLE_PATH so adding wasi-sdk/cmake to CMAKE_MODULE_PATH should do it.

[sbc100]

Can you see if this fixes it: #182

[yamt]

It is great to have wasi.cmake and we use it in several projects (ethash,evmone), however during integration we have noticed one shortcoming stemming from the set(CMAKE_SYSTEM_NAME WASI) setting.

CMake will try to find Platform/WASI.cmake, but if missing, it will fall back to the host system. This works okay on Linux systems, but fails on macOS as that will add compiler settings only available/valid for macOS targets.

There are two possible fixes I have found:

1. Copy the platform file to CMake

2. Change/override the `CMAKE_SYSTEM_NAME` to `Linux`

The downside of option 1 is that it requires change to the installed cmake (copying a new file), while using the toolchain file works without any host changes.

We have decided to override the system name in our files, but I wonder if it would make sense to just change it to Linux in this repository. Any opinions? I can submit a PR if that is there's agreement for this change.

If there's any other options on top of the above, please let me know.

does this problem still exist?

i have something using wasi-sdk.cmake from wasi-sdk-16:
https://github.com/yamt/toywasm/blob/102b998214cc2cc9ac01c83982680b18be5af43a/build-wasm32-wasi.sh#L42-L49

i got a few of the following warnings, both on macOS and ubuntu.

System is unknown to cmake, create:
Platform/WASI to use this system, please post your config file on discourse.cmake.org so it can be added to cmake                                               

despite the above warnings, it seems to build a reasonable wasm binary.

Note: my project's CMakeLists.txt doesn't use the WASI variable provided by Platform/WASI.cmake at all.

Note: while setting CMAKE_MODULE_PATH reduces the number of the warnings, it doesn't eliminate all of them. it guess it's related to try_compile used by check_ipo_supported.