Re: [MirageOS-devel] the windy dunes of mirage: a tooling update

[Hannes Mehnert <hannes@xxxxxxxxxxx>]

Hello,

thanks for your mail. I'm still wondering, especially about:

On 27/03/2019 17:57, Anil Madhavapeddy wrote:
> - Monorepos: Dune supports assembling monorepos by placing packages into a 
> subdirectory, and building it all in one go with a toplevel `dune build` [1]. 
>  I’ve got a simple prototype tool that assembles so-called ‘duniverses’ as a 
> simple way to track all source code that goes into a unikernel in one git 
> repo [3].  The workflow with this is amazing for revving mirage-types, since 
> it can be done in a single go instead of having 10+ opam pins.

I'd appreciate some more detailed instructions how I'd use this. I've
heard there are plans to integrate this into the mirage CLI -- would
this mean a mirage pull would clone all the dependencies?

> - Configuration: Dune has a ‘configurator’ library that is just another build 
> target, so we can unify many of the hacks around pkg-config in one place

What is the status of this? Is pkg-config gone yet? Does this change how
"cross-compilation" of C primitives works (i.e. the way
bigstringaf/checkseum are built)?

> - Lucas ported some packages to dune in order to make this work, and now all 
> of mirage-skeleton builds using dune! Forked packages are available in the 
> mirage-dev remote (https://github.com/mirage/mirage-dev/tree/dune).

That's great! To which extend? Is opam no longer needed once mirage is
installed?

> - For packages where upstreams are busy or dont want to change build systems, 
> there is a https://github.com/dune-universe organisation where we can stage 
> ports to dune (normally via overlays). These forks have to be managed 
> carefully, but are very useful for packages such as Zarith that have 
> extremely subtle build requirements 
> (https://github.com/ocaml/Zarith/compare/master...dune-universe:duniverse-master)

Is this "dune-universe" automatically used instead of the
opam-repository? I noticed there are various outdated clones in the
dune-universe organization - some have dunified releases upstreamed.
Which tool uses dune-universe (i.e. mirage with Lucas' changes)?

> If you have any questions, concerns or feature requests, now is a good time 
> to bring them up.

For me, the main question is: how do I get started to use this? Did the
developer workflow change (can we document the workflow now)?

While working on some unikernels over the last weeks, and rewriting a
library used by them (which somehow turned into 14 opam packages), I had
to do:

(a) work on library...
library$ git commit -m . .
library$ opam remove .
library$ opam pin add -y `pwd`#HEAD
unikernel$ mirage clean
unikernel$ mirage configure -t hvt --prng fortuna
unikernel$ make
(b) fix up unikernel with API changes

This is not very pleasant, since its multiple steps where I usually
forget one (e.g. the git commit, then opam doesn't pick up the changes,
or opam remove . in which case opam doesn't reinstall the packages but
claims nothing changed).  Also, the mirage clean is necessary for mirage
to pick up modified opam libraries.

In respect to the changes above, is there a better story?

Another remark/question: I actually developed side-by-side 5 unikernels,
the above opam pin path installs the library globally, which means that
I can do mirage configure && make in any of the unikernel
subdirectories. With a monorepo, I have the same library cloned for each
unikernel!? Or can I clone the library once and do some symlinks from
the unikernel directory to the library directory?


TL;DR: is there a call for testing with more detailed instructions how
to get started? I'd love to try this out.


hannes

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