Re: opam and myocamlbuild.ml files

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 26 Aug 2012, at 11:38, Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx> 
wrote:

> 
> On 26 Aug 2012, at 01:52, Anil Madhavapeddy wrote:
> 
>> To follow up on this, we should *not* introduce a compile-time dependency
>> on OASIS at this stage.
>> 
>> The reason is that our tool-chains don't do a very good job of cross-compiles
>> and so a 'mirage-3.12.1-xen' OPAM toolchain might not be capable of producing
>> UNIX binaries.
> 
> hm- i guess i don't use the -xen toolchain very often - could you expand a 
> bit on why this is an issue?  (or is that tantamount to just fixing it cf the 
> mirage/bsd comment below? :)

In the Mirage/Xen stdlib, we overwrite various core libraries with the 
Xen-specialised version (notably Bigarray).  So if we use happen to use those 
changed libraries in a bit of code intended for UNIX delivery, things go wrong.

The reason is a pretty standard problem in cross-compilation: we need to 
separate the *host* toolchain from the *target* toolchain.  

The host toolchain includes all camlp4 extensions (which only run during the 
compilation process), and also any platform binaries such as OASIS that are 
used to regenerate makefiles.

The target toolchain is all the code that eventually makes it into the binary, 
including the *output* of the camlp4 host extensions (which is standard OCaml 
code).

Solving this comprehensively will require phase 2 of the Grand Packaging Plan, 
which is to extend OPAM to integrate with the build system of the applications. 
 Thomas/OCamlPro have already begun this via the ocp-build system (which is 
used to build OPAM), but it's a little while away from being usable within 
Mirage itself.

For the moment however, there is no need to panic.  Aside from OASIS itself, 
there isn't a driving need to separate the toolchains until we come to the 
FreeBSD target (which is really very sensitive to issues such as the presence 
of floating point).

> 
>> And of course, when you are in 'OPAM xen mode', you cannot access the OASIS
>> binary, which is probably installed in 'system' mode (in ~/.opam/system/bin).
>> I've reverted the DNS dependency on OASIS which fixes the problem for now.
> 
> ok- what's the current "best practice" as a replacement for OASIS?

Nothing!  Just use OASIS, but checkin the generated files, and all will just 
work.

However, if your library needs C extensions, then somewhat more delicate 
surgery will be required.  I'm working on that for Cryptokit at the moment, as 
ocaml-dns now has a requirement on that due to the DNSSEC code.

-a