[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Current state of the UNIX backend
On 24 May 2013, at 19:23, Vincent Bernardoff <vb@xxxxxxxxxxxxxx> wrote: > Hi all, > > Apparently, the current state of mirage for UNIX-direct is broken for me. > > Could you test it for me, Mac users: > > cd mirage-skeleton/basic > mirari configure --unix > mirari build --unix > sudo ./mir-hello > One very quick thing I noticed is that the 4.01.0dev+mirage-unix compiler is a bit out of date, as it used the old ocplib-endian branch back when the function inlining was added by Pierre. I've modified the compiler descriptions to use ocaml-4.01.0-trunk now, which has those changes and a lot more. However, it does point to the fact that we can separate the compiler dependency from the package dependencies much more easily now, thanks to OPAM. We have these compilers: - 4.00.1 : stable release. - 4.01.0dev+trunk : latest trunk, currently being released. - pierre's new inline branch [1] OPAM can build custom package sets against a compiler without reinstalling it, by doing "opam switch 4.00.1+custom --alias-of=4.00.1". This is a fast clone, and then a package set can be installed in there just like a normal compiler switch. So, we don't actually need 4.00.1+mirage-unix/xen as a compiler switch any more. I propose simply adding these packages to mainline OPAM: - mirage-platform-unix (conficts: mirage-platform-xen) - mirage-platform-xen (conflicts: mirage-platform-unix) - mirage-net-socket (conflicts: mirage-net-direct) - mirage-net-direct (conflicts: mirage-net-socket) The mirage-platform-* packages can provide a mirage ocamlfind package as normal. The only thing I think we need that is missing is a virtual OPAM package that depends on either variant, so that upstream packages like mirage-www can just depend on "mirage-platform" instead of a specific variant. Thomas, I need your opinion on if this is sensible or not. It would eliminate the need for the MIRAGE_NET/OS environment variables, and push the remaining platform selection logic into OPAM, so that Mirari can just install the right set of packages depending on what users want. [1] described in http://www.ocamlpro.com/blog/2013/05/24/optimisations-you-shouldn-t-do.html > On my test machine it fails with: > > Fatal error: exception Unix.Unix_error(3, "set_nonblock", "") I'm recompiling now to try this out! -anil
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |