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

Re: [MirageOS-devel] build workflow


  • To: mirageos-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Drup <drupyog+caml@xxxxxxxx>
  • Date: Fri, 2 Dec 2016 13:50:11 +0100
  • Delivery-date: Fri, 02 Dec 2016 12:50:20 +0000
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=zapps768; d=zoho.com; h=subject:to:references:from:message-id:date:user-agent:mime-version:in-reply-to:content-type; b=HmgTYr7K8GwPtrxgnkUg3QNtTbv43yItN2YXPO0UNs1iIxDo3nukiypMzOyvViVTZy2sjV53kfPh J3eUPp1sH3CTRO/2EaIxtpC5VwSy3OQhKZPQBB6iDVFoZzfQ5mTm
  • List-id: Developer list for MirageOS <mirageos-devel.lists.xenproject.org>

Le 02/12/2016 à 13:38, Martin Lucina a écrit :
On Thursday, 01.12.2016 at 09:19, Thomas Gazagnaire wrote:
- mirage configure <options> should recompile the configuration
according to <options>
- mirage build should build, and error out if the unikernel was not
configured upfront
How do you work with multiple target/config in parallel with this workflow? Do 
you need to reconfigure if want to switch between backends?
I don't follow, you need to reconfigure today if you want to switch
backends...

- 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
What would this new "mirage init" do?

I am generally ok with that workflow which improves the current one. I am just 
a bit concerned by the number of intermediate steps and the proliferation of 
subcommands that you need to remember. Can we try to merge some of these 
commands? For instance maybe use `mirage clean --all` instead of `mirage 
distclean`? And `mirage build --deps` instead of `mirage depends`? etc.
A problem with "mirage build --deps" is that "--deps" is an *option*. IMO
this confuses the semantics of build which would become:

   build: Build the unikernel
      [ --deps ]: Install dependencies

In other words, "mirage build --deps" would do the equivalent of what "make
depend && mirage build" does now.

However: This will be confusing for first time users, since they will
almost always want to run with "--deps".


That's mostly what https://github.com/mirage/functoria/pull/87 does, except that "mirage describe" always accepts keys, even if there is a cached configuration. I think it's more consistent, and it gives you the opportunity to see "what happens if I change just that".


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

 


Rackspace

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