Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wasm.mk: disable by default #2065

Merged
merged 1 commit into from
Jan 13, 2024
Merged

Conversation

yamt
Copy link
Contributor

@yamt yamt commented Sep 15, 2023

Summary

Fixes partly: #2046

Impact

Testing

@yamt
Copy link
Contributor Author

yamt commented Jan 11, 2024

do anyone still have any concerns?
it was a bit surprising me that it was this controversial to disable a very experimental feature which is breaking unrelated workloads.

@no1wudi
Copy link
Contributor

no1wudi commented Jan 11, 2024

@yamt I'm sorry to cause you trouble, and I think it's reasonable to add an option to control this behavior.
However, building Wasm applications with NuttX headers in the NuttX build system is a general design rather than just for WAMR. It's just that WAMR was the first to implement these interfaces, so calling the libc here as the NuttX libc would be more appropriate, rather than the built-in libc of WAMR.

Perhaps we could consider renaming the option to INTERPRETERS_WAMR_BUILD_MODULES_FOR_NUTTX_LIBC.

In the future, I will reorganize the implementation related to the Wasm compilation system to make it more reasonable and user-friendly (for example, researching the possibility of using wasi as a build target).

@no1wudi
Copy link
Contributor

no1wudi commented Jan 11, 2024

@xiaoxiang781216 I think we should land this patch first because there are indeed users who use WAMR on NuttX, but they don't need to build applications from within NuttX. This way, the current behavior of compiling certain applications (such as coremark) into Wasm modules by default when the Wasm runtime is enabled will cause unnecessary trouble for them.

@yamt
Copy link
Contributor Author

yamt commented Jan 11, 2024

Perhaps we could consider renaming the option to INTERPRETERS_WAMR_BUILD_MODULES_FOR_NUTTX_LIBC.

i have no problem with the name.

@xiaoxiang781216
Copy link
Contributor

Perhaps we could consider renaming the option to INTERPRETERS_WAMR_BUILD_MODULES_FOR_NUTTX_LIBC.

i have no problem with the name.

it's a pure nuttx option, why need append _FOR_NUTTX_LIBC? INTERPRETERS_WAMR_BUILD_MODULES is enough to represent the intent.

@no1wudi
Copy link
Contributor

no1wudi commented Jan 11, 2024

it's a pure nuttx option, why need append _FOR_NUTTX_LIBC? INTERPRETERS_WAMR_BUILD_MODULES is enough to represent the intent.

In fact, these modules from NuttX's build system shared the same difinition with native NuttX (such as sys/types.h and fcntl.h), they can only works with NuttX now even some function signature is compatible with WAMR's builtin libc.

@yamt
Copy link
Contributor Author

yamt commented Jan 12, 2024

Perhaps we could consider renaming the option to INTERPRETERS_WAMR_BUILD_MODULES_FOR_NUTTX_LIBC.

i have no problem with the name.

it's a pure nuttx option, why need append _FOR_NUTTX_LIBC? INTERPRETERS_WAMR_BUILD_MODULES is enough to represent the intent.

wasm modules are often expected more "run anywhere" than eg. ELF objects.
there is even a standard (well, at least de-facto) system interface available, wasi.
just INTERPRETERS_WAMR_BUILD_MODULES gives me a false impression that it uses wasi.

@xiaoxiang781216
Copy link
Contributor

Perhaps we could consider renaming the option to INTERPRETERS_WAMR_BUILD_MODULES_FOR_NUTTX_LIBC.

i have no problem with the name.

it's a pure nuttx option, why need append _FOR_NUTTX_LIBC? INTERPRETERS_WAMR_BUILD_MODULES is enough to represent the intent.

wasm modules are often expected more "run anywhere" than eg. ELF objects. there is even a standard (well, at least de-facto) system interface available, wasi. just INTERPRETERS_WAMR_BUILD_MODULES gives me a false impression that it uses wasi.

Ok, but it's better to remove _LIBC suffix from the option since many non libc api can expose too.

@yamt
Copy link
Contributor Author

yamt commented Jan 12, 2024

Perhaps we could consider renaming the option to INTERPRETERS_WAMR_BUILD_MODULES_FOR_NUTTX_LIBC.

i have no problem with the name.

it's a pure nuttx option, why need append _FOR_NUTTX_LIBC? INTERPRETERS_WAMR_BUILD_MODULES is enough to represent the intent.

wasm modules are often expected more "run anywhere" than eg. ELF objects. there is even a standard (well, at least de-facto) system interface available, wasi. just INTERPRETERS_WAMR_BUILD_MODULES gives me a false impression that it uses wasi.

Ok, but it's better to remove _LIBC suffix from the option since many non libc api can expose too.

ok, it makes sense.

@xiaoxiang781216
Copy link
Contributor

@yamt please change INTERPRETERS_WAMR_BUILD_MODULES_FOR_NUTTX_LIBC to INTERPRETERS_WAMR_BUILD_MODULES_FOR_NUTTX, thanks.

@yamt yamt force-pushed the disable-wasm branch 2 times, most recently from ab10a56 to b1ecffc Compare January 12, 2024 14:50
@yamt
Copy link
Contributor Author

yamt commented Jan 12, 2024

@yamt please change INTERPRETERS_WAMR_BUILD_MODULES_FOR_NUTTX_LIBC to INTERPRETERS_WAMR_BUILD_MODULES_FOR_NUTTX, thanks.

done

@xiaoxiang781216
Copy link
Contributor

@yamt please change INTERPRETERS_WAMR_BUILD_MODULES_FOR_NUTTX_LIBC to INTERPRETERS_WAMR_BUILD_MODULES_FOR_NUTTX, thanks.

done

but could you sqaush into one patch?

Fixes partly: apache#2046

Also, this fixes warnings like:
```
spacetanuki% ./tools/configure.sh -E sim:wamr
  Copy files
  Select CONFIG_HOST_MACOS=y
  Refreshing...
/usr/local/bin/bash: line 1: /bin/clang: No such file or directory
/usr/local/bin/bash: line 1: /bin/clang: No such file or directory              /usr/local/bin/bash: line 1: /bin/clang: No such file or directory
/usr/local/bin/bash: line 1: /bin/clang: No such file or directory
/usr/local/bin/bash: line 1: /bin/clang: No such file or directory
/usr/local/bin/bash: line 1: /bin/clang: No such file or directory
/usr/local/bin/bash: line 1: /bin/clang: No such file or directory
/usr/local/bin/bash: line 1: /bin/clang: No such file or directory
/usr/local/bin/bash: line 1: /bin/clang: No such file or directory
CP: arch/dummy/Kconfig to /Users/yamamoto/git/nuttx/nuttx/arch/dummy/dummy_kconf
ig
CP: boards/dummy/Kconfig to /Users/yamamoto/git/nuttx/nuttx/boards/dummy/dummy_k
config
/usr/local/bin/bash: line 1: /bin/clang: No such file or directory
/usr/local/bin/bash: line 1: /bin/clang: No such file or directory
/usr/local/bin/bash: line 1: /bin/clang: No such file or directory
/usr/local/bin/bash: line 1: /bin/clang: No such file or directory
/usr/local/bin/bash: line 1: /bin/clang: No such file or directory
/usr/local/bin/bash: line 1: /bin/clang: No such file or directory

```
@yamt
Copy link
Contributor Author

yamt commented Jan 12, 2024

@yamt please change INTERPRETERS_WAMR_BUILD_MODULES_FOR_NUTTX_LIBC to INTERPRETERS_WAMR_BUILD_MODULES_FOR_NUTTX, thanks.

done

but could you sqaush into one patch?

done

@xiaoxiang781216 xiaoxiang781216 merged commit 8930743 into apache:master Jan 13, 2024
25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants