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

Re: [MirageOS-devel] build workflow



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".

Martin

_______________________________________________
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®.