On 11/30/2016 12:28 PM, Hannes Mehnert wrote:
I'm not yet happy with the workflow.

What I'd like to have:
- mirage help should be executable with and without a config.ml -- if
config.ml is present, compile it to show possibilities
- mirage describe should work with and without a configured unikernel
(--eval vs --no-eval)
- mirage configure <options> should recompile the configuration
according to <options>
- mirage build should build, and error out if the unikernel was not
configured upfront
- 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

- 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)

We discussed `-f` for specifying a config file -- did you mean that or something else?

functoria#85 (mirage#712) do not achieve this goal (and should not be
merged).

Unfortunately this message fell out of my brain and I clicked the nice "merge" button for both of these PRs, since fixing the key persistence across stages seemed like a good idea to me. I can revert, but I'm not convinced that the state with them merged is worse than without.

-Mindy


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

Reply via email to