We should properly document the binaryen upgrade process to make it easier and prevent mistakes.
Currently, from what I know the process is as follows:
- Update the
libbinaryen version in package.json and binaryen.opam
- Diff the current version to the next version.
- Check the diff for
src/binaryen-c.h changes api changes
src/js/binaryen.js-post.js api changes
- Changes to
PassRegistry::registerPasses in src/passes/pass.cpp
Any api's that have been removed from binaryen-c.h should be removed from our binaryen.ml api, you can search the project and remove their corresponding .c, .js, .ml, .mli and test.ml file. Any trivial api's that are added should be implemented, assuming they exist both in the c and js api's (smoke tests should be implemented as well), and the passes should be updated to match binaryen's correctly.
Any larger api's that are added should ideally have a separate pr submitted alongside the release; however, given the amount of work to implement these api's, an issue can be opened instead.
We should properly document the binaryen upgrade process to make it easier and prevent mistakes.
Currently, from what I know the process is as follows:
libbinaryenversion inpackage.jsonandbinaryen.opamsrc/binaryen-c.h changesapi changessrc/js/binaryen.js-post.jsapi changesPassRegistry::registerPassesinsrc/passes/pass.cppAny api's that have been removed from
binaryen-c.hshould be removed from our binaryen.ml api, you can search the project and remove their corresponding.c,.js,.ml,.mliandtest.mlfile. Any trivial api's that are added should be implemented, assuming they exist both in thecandjsapi's (smoke tests should be implemented as well), and the passes should be updated to match binaryen's correctly.Any larger api's that are added should ideally have a separate pr submitted alongside the release; however, given the amount of work to implement these api's, an issue can be opened instead.