Re: [MirageOS-devel] build workflow

[Mindy <mindy@xxxxxxxxxxxxxxxxxxx>]

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