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
The easiest way for projects to integrate the wasm-opt API will be if they can continue using their existing CLI arguments instead of using the builder API directly. e.g. I imagine cargo-contract will want to continue having the ability to optionally use the wasm-opt CLI for some period until they are confident removing that code. To avoid having two code paths, it will be easier for them if the wasm-opt API can just handle the same CLI arguments they are already using.
Create an integration module with a single function, run, that accepts std::process::Command
Iterate over all the arguments of that command to create an OptimizationOptions, while also pulling out the input file, output file, input sourcemap, and output souremap paths.
Call OptimizationOptions::run
Return an error for any command line options that aren't understood.
We implement this on a best-effort basis to support whatever actual integrators need, for now just cargo-contract. It doesn't need full fidelity with exactly everything the wasm-opt CLI can parse, as long as integrators can craft a single command that works with both the "real" wasm-opt and the API.
cargo-contract needs these arguments:
the input file
"-o" output file
"-On"
"--zero-filled-memory"
"-g"
We can get that working, and should probably go ahead and support all CLI equivalents for everything the builder API supports.
The text was updated successfully, but these errors were encountered:
The easiest way for projects to integrate the wasm-opt API will be if they can continue using their existing CLI arguments instead of using the builder API directly. e.g. I imagine cargo-contract will want to continue having the ability to optionally use the wasm-opt CLI for some period until they are confident removing that code. To avoid having two code paths, it will be easier for them if the wasm-opt API can just handle the same CLI arguments they are already using.
integration
module with a single function,run
, that acceptsstd::process::Command
OptimizationOptions
, while also pulling out the input file, output file, input sourcemap, and output souremap paths.OptimizationOptions::run
We implement this on a best-effort basis to support whatever actual integrators need, for now just
cargo-contract
. It doesn't need full fidelity with exactly everything the wasm-opt CLI can parse, as long as integrators can craft a single command that works with both the "real" wasm-opt and the API.cargo-contract needs these arguments:
We can get that working, and should probably go ahead and support all CLI equivalents for everything the builder API supports.
The text was updated successfully, but these errors were encountered: