Re: [MirageOS-devel] build workflow

[Martin Lucina <martin@xxxxxxxxxx>]

On Thursday, 01.12.2016 at 19:10, Drup wrote:
> 
> >I'm now wondering: what was the rationale for having `mirage describe`
> >vs `mirage help` at all?
> >Maybe it would be better to incorporate the tty-output options of
> >`describe` into the `help` output, and have `mirage describe` only
> >produce the `--dot` output using the cached result of `mirage
> >configure` if available, or not if not?

Expanding on this:

> "mirage help" describes the tool. In particular, it works without a config
> file.

There's also "mirage configure --help" which describes what configuration
options the unikernel accepts.

> "mirage describe" describes the unikernel. It only works with a config file.

As others have already mentioned, at least "mirage describe --dot" is
useful in an unconfigured context.

> We must be careful about error modes without/without a config file: they are
> already quite a nightmare currently, and I'm a bit wary of merging these two
> commands, as it'll only make things worse.

Agreed, they should not be merged. To summarize, I think we should have the
following:

1) Irrespective of configured/unconfigured state, i.e. no change in
behaviour:

- mirage help: documents Mirage tool invocation
- mirage configure --help: documents Unikernel configuration

2) Unconfigured state:

- mirage describe [ OPTIONS ]: does what it does today without --eval, i.e.
describes the effect of *possible* dependencies.

3) Configured state:

- mirage describe: does what it does today with --eval. Does not accept
configuration keys.

Martin


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