One of the things missing is a way to say the codegen name in the runtime.Module without overloading type_key.
I agree. I don’t know exactly the best way to proceed here–we likely need another RFC. The limitation is that with C++ runtime, the external compiler in BYOC is expected to produce runnable artifacts. In µTVM, we just expect compilable artifacts. This is a whole different can of worms: it’s likely we’ll produce a bunch of similarly-formatted runtime.Module (i.e. .o, .c) which may nonetheless need special treatment downstream in the Project generator. Therefore I think it makes sense to identify them somehow to do the export grouping. However, I don’t know whether it would make sense to add another type_key-like thing or just stick with type_key and provide extensible Module impls in C++ land. It would be helpful to think through a case where a specialized compiler is required downstream (I.e. something like a CUDA compiler) which produces object code not targeted to target_host.
However, a draw-back of this approach is Project-API that consume this will need to be aware of the folder structure based on composite target. Do we need that complexity ?
The case I mention at the end of the above is the case I’m thinking of where it would be helpful to separate things. The C++ BYOC interface is: “produce a runnable Module in external compiler and serialize/deserialize through binary blob.” I think given we don’t expect external compilers to produce code that compiles on target_host, we should create an explicit namespace that may not include c code here.