[hannk] Add support for building/running for wasm #6361
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Preparatory work for allowing building of hannk with Emscripten; TFLite (and its dependees) problematic to build in that environment, but this will allow us to build a tflite-parser-only environment. (Note that more work is needed to get this working for wasm, as crosscompiling in CMake is still pretty painful; this work was split out to make subsequent reviews simpler)
Cross-compiling in CMake is always a train-wreck... do you mind if I push some changes to this branch to clean up the CMake? I can also do it as a PR-to-PR if you prefer. |
Nah, please, go right ahead :-) |
* Ignore local emsdk clone * Fix usage of CMAKE_BUILD_TYPE * Only print the Halide target info once per CMake run * Fix Halide "cmake" target detection for Emscripten * Prefer target_link_options to _link_libraries when applicable * Validate, rather than find, NODE_JS_EXECUTABLE (set by emsdk) * Emscripten already wraps tests with node. * Add dependency on Android logging library. * For cross-compiling, find host tools instead of recursive call. Rather than shelling out via execute_process and potentially guessing the toolchain options wrong, expect to find our host tools (i.e. generators) in a package called "hannk_tools". The package is created by the host build via the CMake export() command. Importing this package in the cross build creates IMPORTED targets with the same names as our generators. We then use these generators rather than creating generators for the target build. * Rework cross-compiling script. * Respond to (easy) reviewer comments. * Add HANNK_AOT_HOST_ONLY option. Use in script. * [hannk] tests should only process .tflite files (#6368) currently, random dotfiles (e.g. .DS_Store on OSX) can creep in, causing bogus failures * Add comment about node wrapping. * Rename hannk_tools to hannk-halide_generators * Add comment about exporting targets. * Bump version to Halide 14.0.0 (#6369) Co-authored-by: Steven Johnson <srj@google.com>
|
With #6365 merged into this branch, this should be good to go once the buildbots go green |
Sounds good to me. I have another PR queued up that switches HANNK over to using the helpers introduced in #6366. It also reworks cross-compiling detection and makes one call to ninja rebuild the world 👍 It's ready to go, provided we can get both PRs merged. |
alexreinking
approved these changes
Nov 1, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds limited support for building and running hannk under WebAssembly. (Note that this requires #6360 to land first.)
Requirements:
Caveats: this uses some seriously janky tricks for cross-compiling (all in apps/hannk/halide/CMakeLists.txt); the basic idea is that when crosscompiling, we re-run CMake on the subdirectory, but with an attempt to revert to the default host tooling (rather than what Emscripten has put in place), then set up dependencies to build and run the Generators that way, and then re-connect the generated libraries in the enclosing CMake file.
This works for me locally, and may be acceptable for an app of this sort. (Whether it is robust enough for "real" apps is not clear.) As usual, @alexreinking, I welcome your cmake-fu to let me know whether this is liable to break immediately and/or could be improved. (If this approach actually seems reasonable, it might be good to find a way to generalize it to allow easier wasm builds of other apps...)
I'm going to go ahead and request a review for this, but it may well need more attention before landing.