Support compilation to wasm target
Changes
- added new
wasmmod for supportinggetandsetAPI forwasitarget. getmethod for hostname will always returns static stringwasihost- https://github.com/WebAssembly/wasi-libc/issues/196#issuecomment-620933143setmethod for hostname is emulated
Hi, @mdrokz , thank you for your PR!
Yet, I do not understand the purpose of those changes: it does not returns actual hostname (due to linkage issue you mentioned) and set() function is a stub.
How can it be useful for crate users?
Hi, @mdrokz , thank you for your PR!
Yet, I do not understand the purpose of those changes: it does not returns actual hostname (due to linkage issue you mentioned) and
set()function is a stub. How can it be useful for crate users?
Hi,
this just adds support for wasm target there are lot of crates that depend on this one, for example the lettre and lettre_email crate if i want to compile lettre for wasm then the compilation would fail because this crate doesnt support wasm target.
Hey!
I'm not sure if that is the approach I want to follow: if some particular target is not supported, I personally would prefer to learn about that fact during the compilation.
I can imagine it will be very confusing to figure out in runtime why returned value is very different from the actual system hostname. Even returning some blank error like std::io::Error with std::io::ErrorKind::Unsupported all the time might not fit all use cases.
On the other hand, with compilation failure each of the crate consumers can choose what approach to use: not provide support for this target at all or use some "default" value instead with conditional compilation like in the following pseudo-code (sorry, writing from my head, might have some naive mistakes):
#[cfg(any(target_family="unix", target_family="windows"))]
use hostname::get as get_hostname;
#[cfg(not(any(target_family="unix", target_family="windows")))]
fn get_hostname() -> io::Result<OsString> {
"unknown".into()
}
Anyway, so far I'm inclined not to accept this PR, but I'm open for further discussion, of course, and having a wasm support would also be great.