[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] build workflow

[ May not be able to make the call tonight, so in lieu of that my
responses to Martin's questions below ]

On 30 November 2016 at 11:09, Martin Lucina <martin@xxxxxxxxxx> wrote:
> I'd also like to propose/discuss the following followup changes:
> 1. Now that we have more targets for Mirage 3.0, we should no longer have
> any default at all and instead error out if no target is specified. I.e.
> "unix" will no longer be the default.

Yes-- my preference would be error out rather than default.

> 2. The "mirage describe" subcommand should pick up keys persisted as a
> result of a previous run of "configure". Also, it might be a good idea to
> have consistent behaviour with "build" here and error out if "configure"
> has not been run first. I've filed mirage/mirage#713 for this.

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?

> 3. Should there be a subcommand ("depend") that does the equivalent of
> "make depend" in the new order?

Possibly the answer is "yes" but probably not yet.

ISTR bringing back `mirage build` was discussed on an issue recently,
but my understanding of the consensus was to defer that until we had a
clearer picture of exactly what needed to be done there, what the
extra hooks/control was we needed over build that wasn't available via
`make`, etc. I would imagine that we might discuss adding extra
subcommands when we revisit that workflow. (Do we need a separate
`depend` step, or will `mirage build` just sort it all out?)

> Thanks to Hannes for the work on the "New order" workflow changes and
> everyone else for their help with testing and review!

Yes! It's really nice to see all of this getting smoothed out so well,
and the new targets coming in :)

Richard Mortier

MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.