Re: [MirageOS-devel] build workflow

[Martin Lucina <martin@xxxxxxxxxx>]

On Wednesday, 30.11.2016 at 06:20, Mindy wrote:
> On November 30, 2016 5:44:42 AM CST, Martin Lucina <martin@xxxxxxxxxx> wrote:
> >On Wednesday, 30.11.2016 at 11:35, Richard Mortier wrote:
> >> On 30 November 2016 at 11:32, Martin Lucina <martin@xxxxxxxxxx>
> >wrote:
> >> > On Wednesday, 30.11.2016 at 11:25, Richard Mortier wrote:
> >> >> I thought one of the things `mirage describe` could do was display
> >> >> information about possible configuration options -- ie., it's
> >useful
> >> >> to *not* have to run `mirage configure` first and actually set
> >those
> >> >> options explicitly?
> >> >
> >> > Isn't that what "mirage configure --help" is for?
> >> 
> >> I thought `describe` gave the .dot output, visualising the configure
> >> graph too (but before it was constrained by the configure options the
> >> user specifies)?
> >
> >That's one of the things it does, if you ask for it with "--dot".
> >Running
> >it with no arguments gives output like this:
> >
> >Name       stackv4
> >Root       /home/mato/solo5/mirage-skeleton/stackv4
> >Keys       dhcp=false (default), gateway=10.0.0.1 (default),
> >interface=tap0 (default), interfaces=0.0.0.0 (default), logs=
> >(default),
> >net=direct (default), network=10.0.0.2/24 (default), prng=stdlib
> >(default),
> >  socket= (default), target=unix (default), warn_error=false (default)
> >
> >Martin
> >
> >_______________________________________________
> >MirageOS-devel mailing list
> >MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> >https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
> 
> Running `mirage describe --eval` considers the values of keys and collapses 
> the graph as appropriate -- perhaps that's what you're looking for?

Ah, I remember asking about this before, it's somewhat non-obvious.

It seems that the change to persist arguments in functoria#85 actually
affects all subcommands after running "configure". This has a surprising
interaction with describe:

Starting with a cleaned tree of stackv4, with functoria#85 pinned, and
omitting some of the intermediate build output:

$ mirage describe
Name       stackv4
Root       /home/mato/solo5/mirage-skeleton/stackv4
Keys       dhcp=false (default), gateway=10.0.0.1 (default),
  interface=tap0 (default), interfaces=0.0.0.0 (default), logs= (default),
  net=direct (default), network=10.0.0.2/24 (default), prng=stdlib (default),
  socket= (default), target=unix (default), warn_error=false (default)
$ mirage describe --eval --dhcp=true
Name       stackv4
Root       /home/mato/solo5/mirage-skeleton/stackv4
Keys       dhcp=true, interface=tap0 (default), logs= (default),
  net=direct (default), prng=stdlib (default), target=unix (default),
  warn_error=false (default)
$ mirage configure -t ukvm --dhcp=true
...
$ mirage describe
Fatal error: exception (Failure "No socket implementation available for 
unikernel")
$ mirage describe -t ukvm
mirage: option `-t' cannot be repeated
Usage: mirage describe [OPTION]... 
Try `mirage describe --help' or `mirage --help' for more information.
$ mirage describe --eval
Name       stackv4
Root       /home/mato/solo5/mirage-skeleton/stackv4
Keys       dhcp=true, interface=tap0 (default), logs= (default),
  net=direct (default), prng=stdlib (default), target=ukvm,
  warn_error=false (default)
$ mirage describe --eval --dhcp=false
mirage: option `--dhcp' cannot be repeated
Usage: mirage describe [OPTION]... 
Try `mirage describe --help' or `mirage --help' for more information.

IMO the expected behaviour should be:

1. always run as "mirage describe --eval",
2. error out if not configured
and 3. not accept any further configuration-changing keys.

But this may not be everyone's use case for "mirage describe"...

Martin

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