> - mirage configure <options> should recompile the configuration
> according to <options>
> - mirage build should build, and error out if the unikernel was not
> configured upfront

How do you work with multiple target/config in parallel with this workflow? Do 
you need to reconfigure if want to switch between backends?

> - mirage clean should always remove build products (_build), not depend
> on any concrete configuration
> - mirage distclean (new!) should clean and remove all generated things
> - mirage init (new, proposed by samoht) should be usable without a config.ml

I am generally ok with that workflow which improves the current one. I am just 
a bit concerned by the number of intermediate steps and the proliferation of 
subcommands that you need to remember. Can we try to merge some of these 
commands? For instance maybe use `mirage clean --all` instead of `mirage 
distclean`? And `mirage build --deps` instead of `mirage depends`? etc.

Thomas

> - whenever config.ml changed (mtime is more recent than its build
> product), build should error, describe should error (if --eval becomes
> the default, as suggested by mato)
> 
> - should mirage help behave differently if there is a configured
> unikernel (and do whatever mirage describe does)?
> 
> - only the configure subcommand should take command line arguments,
> build/etc. should only take verbosity arguments
> 
> - as mentioned in the call today, I think -c can be removed (introduces
> unnecessary complexity)

> functoria#85 (mirage#712) do not achieve this goal (and should not be
> merged).
> 
> 
> does this sound good?  do I miss something?
> 
> hannes
> 
> 
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@lists.xenproject.org
> https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

Reply via email to