Re: [MirageOS-devel] build workflow

[Drup <drupyog+caml@xxxxxxxx>]

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