Lunderberg commented on pull request #9970:
URL: https://github.com/apache/tvm/pull/9970#issuecomment-1016937131
I like the idea of simplifying the build process, but I'm worried that this
would make it more difficult for developers to test changes. This PR would
reduce the complexity of the existing cmake setup, but I think it would result
in passing that complexity to the developer to manually handle.
Build details, as I understand them.
* Three TVM builds are required. (Host, connected Android, connected
Hexagon)
* Each of the three builds has different values for the RPC and
static/dynamic options.
* All three builds must have the same values for several build variables.
* Hexagon: `USE_HEXAGON_SDK` and `USE_HEXAGON_ARCH`
* Android: `USE_ANDROID_TOOLCHAIN`
* All three builds must have be built from the same version of TVM.
* All three builds must output to the same location (currently
`$BUILD_DIR/apps/hexagon_*`).
Brainstorming on options
* Option 1: Top-level TVM CMake launches the three independent builds as
external projects
* Current implementation on main.
* Pro: Developer can run `make && run_my_test.py` to rebuild all three
tests in a single step.
* Con: Difficult to manage setup.
* Option 2: Developer launches the three independent builds
* Current implementation in this PR.
* Pro: Easier to manage cmake setup.
* Con: Interactions between the three builds must be handled by each
developer, either manually or by writing a wrapper build script.
* Con: Removes the app from the TVM framework. Compiling TVM is no longer
sufficient to use `tvm.contrib.hexagon`.
* Option 3: App Cmake launches all three independent builds
* Pro: Developer can run tests from a single location
* Pro: Includes occur only in one direction, from the app to the TVM build.
* Con: Removes the app from the TVM framework. Compiling TVM is no longer
sufficient to use `tvm.contrib.hexagon`.
Between the high-level options, I'd prefer Option 1, since it would maintain
the same developer-facing interactions. Thoughts?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
