You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As requested by @loganek creating a new feature to track this improvement
Feature
Compile Time
At compile time a list of the features enabled and the features not-enabled are displayed to the user.
Runtime Help
At runtime the iwasm tool can list the features it has enabled and the features which are not enabled with -v or with --help
Runtime Failure Improvement
The main result of a feature miss match between a .wasm file and the runtime is a parsing error. When a parsing error occurs WAMR should output the list of features it has enabled and ask the user to check that this matches the feature enabled by the compiler that produced the .wasm file.
Community Suggestion
We could suggest to the compiler / tool chain folks that they think about including a custom section with a list of the features enabled by the compiler when the .wasm file was produced. It would be easy to remove this custom section to reduce binary size, but it would provide useful information to the user.
Benefit
Different languages and compiler tool chains are changing the feature sets they use by default. This results in users compiling their application to Wasm and seeing error messages when attempting to execute them. The error messages are confusing and often cause hours of debugging by Wamr users. e.g.
Compiling without references -> error message about expecting a zero byte
Compiling without exception handling -> error message about an unknown type section
Displaying the sets of features which are enabled and disabled is a quick way to allow the user identify the issue themselves.
Implementation
There are a set of features enabled for all platforms and set of features enabled for specific platforms so it is not always clear for new users when switching between platforms.
Alternatives
TODO: What are the alternative implementation approaches or alternative ways to
solve the problem that this feature would solve? How do these alternatives
compare to this proposal?
> > Mentioning the options selected during the build process - and the options not selected would be really great improvement.
AFAIK some of the options are printed when generating CMake file, but some of them are not. Also, it'd be good to print the enabled features when user calls iwasm --help or iwasm -v. Would you mind open an issue so we can track the improvement?
As requested by @loganek creating a new feature to track this improvement
Feature
Compile Time
At compile time a list of the features enabled and the features not-enabled are displayed to the user.
Runtime Help
At runtime the iwasm tool can list the features it has enabled and the features which are not enabled with
-v
or with--help
Runtime Failure Improvement
The main result of a feature miss match between a
.wasm
file and the runtime is a parsing error. When a parsing error occurs WAMR should output the list of features it has enabled and ask the user to check that this matches the feature enabled by the compiler that produced the.wasm
file.Community Suggestion
We could suggest to the compiler / tool chain folks that they think about including a custom section with a list of the features enabled by the compiler when the
.wasm
file was produced. It would be easy to remove this custom section to reduce binary size, but it would provide useful information to the user.Benefit
Different languages and compiler tool chains are changing the feature sets they use by default. This results in users compiling their application to Wasm and seeing error messages when attempting to execute them. The error messages are confusing and often cause hours of debugging by Wamr users. e.g.
Displaying the sets of features which are enabled and disabled is a quick way to allow the user identify the issue themselves.
Implementation
There are a set of features enabled for all platforms and set of features enabled for specific platforms so it is not always clear for new users when switching between platforms.
Alternatives
TODO: What are the alternative implementation approaches or alternative ways to
solve the problem that this feature would solve? How do these alternatives
compare to this proposal?
To Keep the Conversation Going from #3978
I am creating a new document about which wasm proposals are on-by-default and which are off-by-default. Are you suggesting we should output something like that during cmake configuration and execution by
iwasm
?Might need to add the library case
Originally posted by @lum1n0us in #3978 (comment)
The text was updated successfully, but these errors were encountered: