Re: [MirageOS-devel] mirage configure & dynlink (was: V1 vs V2 mirage-types)

[Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>]

> It seems to me that it would be better for each mirage library to
> manage its own code generation.  In this world, `mirage configure`
> would be a library of combinators used to write these code generators
> and the individual code generators would be loaded dynamically (using
> dynlink & findlib) at configure time.

Actually, this is already almost possible (but not very well tested). Each 
implementation should be able to export some combinators using:

https://github.com/mirage/mirage/blob/master/lib/mirage.mli#L495

The "hard" is to link "config.ml" with the right libraries. Currently, this is 
using ocamlbuild + dynlink:

https://github.com/mirage/mirage/blob/master/lib/mirage.ml#L2344

This could be extended to add extra "-pkg" arguments, that the user could 
specify.

 Or we can do as in Assemblage, where "config.ml" is interpreted as a raw text 
file by the toplevel (so allowing #require in it). 


> I haven't thought through this idea, but I was wondering what other
> people thought about it.

The only problem with specifying configuration combinators in the libraries is 
that then you need to know in which ocamlfind / opam package to look for them. 
Currently the mirage tool has that knowledge (so it can generate the "depends" 
rule in the Makefile to install the right opam packages). I am not totally sure 
how to fix that properly (but maybe, that's not so much a problem in practice, 
as you might always know which library you want to use).

But that's certainly a much flexible solution than the current monolithic one 
...

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