Re: opam and myocamlbuild.ml files

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 19 Jul 2012, at 01:33, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:

> On Tue, Jul 17, 2012 at 07:13:09PM +0100, Richard Mortier wrote:
>> 
>> On 17 Jul 2012, at 18:27, Anil Madhavapeddy wrote:
>> 
>>> On 17 Jul 2012, at 17:52, Richard Mortier
>>> <Richard.Mortier@xxxxxxxxxxxxxxxx> wrote:
>>> 
>>>> 
>>>> On 17 Jul 2012, at 10:35, Anil Madhavapeddy wrote:
>>>> 
>>>>> Good question.  We could move to only generating the setup.ml for
>>>>> stable releases, and not for the working copy.  The diff spam is
>>>>> really irritating when bug bisecting...
>>>> 
>>>> agree; at risk of repeating in other mail- could we even just move to
>>>> oasis being a dependency and let opam handle it?
>>> 
>>> Could do; but that would require different OPAM files for dev and
>>> releases. Just needs someone to make sure that works...
>> 
>> hm- don't follow. why does that require different opam files?
>> 
>> (perhaps a more general question here is- what's the difference in
>> concept between dev and release versions of an opam package?)
> 
> A release package would ideally not require a dependency on OASIS, as its
> designed like autoconf: the autogenerated files only need an OCaml
> installation.
> 
> So I was thinking that the dev packages would call "oasis setup" before
> invoking make (to generate the ocamlbuild plugin), and released packages
> would have that done already, to reduce the source dependencies for people
> not using OPAM (which, believe it or not, is most people).

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.

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.

There'll be plenty of time to worry about cross-compilation when integrating
Gabor's kFreeBSD backend at the same time, which is even more sensitive to
such issues than the Xen one :-)

-anil