Re: [MirageOS-devel] build workflow

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

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)

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel