Great, let’s discuss Model Library Format a bit further on another RFC. I will try to start one early this week.
Cool. Thanks 
and a new command
tvmc micro gen-project(or something) would be added to generate the e.g. Zephyr project.oh that’s cool. Copying (or generating) it from the template dir you mentioned right?
Yes. However, to refine this a bit and address a comment you made earlier to @manupa-arm: this template project shouldn’t get used if we are just producing Model Library Format. The idea of the template project is to provide the necessary boilerplate/glue to configure an SoC to run a model given one in Model Library Format. The template project is tied to the implementation of the Project-level API.
Right, I got that tvmc micro gen-project is just for creating (for instance) a project template for a given microTVM project, like one that will use Zephyr’s SDK, so no need to use for the other use-cases that use Model Library Format (and that don’t use the Project-API).
On my comment to @manupa-arm I was just wondering if it would make sense to use a template (a different one from project template) for use-cases like the static runtime in apps/bundle_deploy, since in my understanding the code in bundle.c (and bundle.cc) is a just a boilerplate/glue that will be used in similar use-cases. In that case a compile flag would exist specifying a static runtime (tvmc currently only generates a .so afaics) (like, --static-runtime) and the template would be copied to Model Library Format into src/ so the user could later easily use it in conjunction with other sources generated by build.relay on a Makefile. The advantage in my view, if that’s possible, would be to avoid repeating it boilerplate on each application that wants to use a static runtime.
Here I mean–if we are going to include something to describe the device configuration (similar to the
--target=zephyr -target=stm32f746xx -board=...you proposed), the portion which describes the project template used should just be the git sha1 from the git repo that houses the template project and the Project-level API implementation.
Got it. OK.
Btw, I’m still struggling to visualize where the Model Library Format (MLF) file will reside by default for the various use-cases. By default I’m thinking of it residing in the current working dir when the Project-API is not used and inside the target project when the Project-API is used.