hi @manupa-arm,
seems like we have two options: O1. build a library version of this [StaticRuntime fcompile function](https://github.com/areusch/incubator-tvm/blob/utvm-runtime/python/tvm/micro/build.py#L217) and make `export_library` call this function to create something like a DSO (instead, it would likely be a static archive .a, but similar idea). the advantage is that the micro flow would retain the same API as the usual export_library flow, although even now the implementation is quite different when exporting a source module. the disadvantage is that we still need to pass a custom fcompile function to allow the user to specify a cross compiler, which is maybe confusing. O2. build a micro-specific `export_library` implementation that knows how to traverse imported modules and compile as necessary. the advantage is that we don't need to go far out of our way to accommodate micro-specific customizations in the library flow, so the user API may be more clear and easier to grow around any future changes we need for BYOC/micro. The disadvantage is that we may duplicate some logic. it probably also depends somewhat whether or not your BYOC will generate C source or object code (it should be possible now to generate µTVM operators using the llvm backend, but we haven't tried it yet). for the constant artifacts, you should be able to produce a binary `.o` that's linked the same way as any BYOC-generated code. it seems like we should modify [`build_static_runtime`](https://github.com/apache/incubator-tvm/blob/master/python/tvm/micro/build.py#L94) to learn how to build these companion artifacts, or otherwise move this into an e.g. `build_micro_library` function. thoughts? @tqchen --- [Visit Topic](https://discuss.tvm.apache.org/t/external-modules-in-utvm/7993/2) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/5f178e940ff6a4e67ed2d8661d7cd0cb6537e5a29f6c4d5547171b9f323b023e).
