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

Re: [MirageOS-devel] Cross-compiling OCaml, Mirage OS for rumprun, OPAM integration

> And, as I just found out now, it's not just the native packages, it's *all*
> packages that need to be rebuilt. So, for Mirage I'd have to produce
> -rumprun variants of all its dependent packages, right? This would include
> teaching the "mirage configure" script about them.

We already partly do that to cross-compile the C stubs for Xen (such as gmp for 
the TLS stack to work on Xen). The upcoming 2.5.0 release of mirage will have 
improved support for this. See gmp-xen[1] and some ugly ocamlfind hackery to 
pass the right options at link time, used by mirage configure[2] when 
generating the Makefile.

Clearly the situation will not scale well as we will have to patch every 
package using C stubs. I'm looking forward to have full support 
cross-compilation in the whole toolchain (to start with the build tools).


[3]: https://github.com/mirage/mirage/blob/master/lib/mirage.ml#L2248

> This begs the question, why did you use the approach of building the
> cross-compiler as a normal OPAM package, rather than as a compiler package?
> If I understand correctly how "OPAM switch" works, then the latter option
> would at least get rid of the need to deal with the -android (or -rumprun)
> renaming of packages since each compiler has its own set of packages.
> Obviously, there'd still have to be some way of getting
> the OCAMLFIND_TOOLCHAIN and/or other cross-compilation patches into the
> system but at first glance it seems like it would be more flexible than
> adding suffixes to package names.
> Thoughts?
> Martin
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.