Re: [MirageOS-devel] [ANN] IPv6 on Mirage!

[Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>]

>> foo-type: the definition of the mirage FOO signature
>> foo: the functors for FOO. Depend on foo-type as we want to check 
>> signature/implementation matching at compile time. Depends on bar-type, 
>> baz-type, etc...
>> foo-unix: the implementation of FOO for unix. Depends on foo.
>> foo-xen: the implementation of FOO for xen. Depends on foo.
>> foo-mirage: the implementation of the combinators for foo-type. Depends on 
>> foo-type. Might add a dependency on a specific versions of foo-unix and 
>> foo-xen if the right combinators are used when used in a config.ml. For each 
>> new versions of foo-unix and foo-xen, we need to upgrade the constraints 
>> (which might be painful) to ensure backward-compatibility. Or we can have 
>> open constraints, and do a minor release with the right updated constraints 
>> before bumping the major version number.
> 
> Can't these simply be subpackages ? Basically the root package foo is 
> foo-type. All other are subpackages (foo.func, foo.unix, foo.xen, foo.mirage) 
> whose existence is conditioned by depopts.  

That's not so simple unfortunately. You might have x-unix and y-unix which both 
satisfy the signature in foo-type. An example: a lot of implementation satisfy 
the KV_RO (key/value store, read-only) signature: ocaml-crunch, mirage-fs-unix. 
mirage-fat, etc.. In that case, it doesn't really make sense to have all of 
them in the same package.

Also, from a dependency point-of-view, I think it's clearer to separate the 
`*-type` packages. All the `*-type` only depends on other `*-type`. The 
libraries are pure cmis, defining base signatures. They only depend on other 
`*-type`. The `X` packages define functors over the base signatures. They only 
depends on other `*-type` modules. I think that quite useful to see that at the 
dependency level, and not clumsy it with some random depots. 

>> $ mirage configure [--xen]
>> 
>> will install either foo-unix or foo-xen automatically, depending on having 
>> [--xen] or not on the command-line (as the mirage tool does currently).
> I think it would be interesting to look if this can be split up a bit with a 
> kind of mirage-get that handles the installation and then use assemblage's 
> new rich configuration system for setting up the build system. If we 
> eventually get to a good default driver (or at least the driver I have been 
> dreaming about, see assemblage's #145), you would then have the ability to 
> live with both the xen and unix build side-by-side without having to restart 
> from scratch each time you switch target.   

Agreed this could be neat. Currently the mirage tool also does some other 
side-effects at configure time:
- it reads config.ml, look for the different base combinators used
- install the corresponding opam package
- generate the corresponding main.ml to use the selected implementations in the 
right order
- eventually generate some other .ml files (crunch, fat, ...)

In the future, some of the things could be done by assemblage -- for instance 
we could provide a Mirage lib for assemblage, to expose the mirage combinator 
in your assemble.ml. But well, that's a quite far future :p

Thomas


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