Re: [MirageOS-devel] Patches for building mirage libraries with `opam2nix`

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 1 Sep 2015, at 04:33, Tim Cuthbertson <tim@xxxxxxxxxxx> wrote:
>> 
>> We should absolutely support a non-OPAM build environment.  That's
>> purely there because of "build laziness", but will also be a problem
>> when it comes to doing upstream packaging into Debian/*BSD/etc.
>> 
>> I haven't reviewed your changes above in detail as I'm about to fly
>> to Vancouver to ICFP, but please do send pull requests and we can
>> discuss them on the relevant GitHub repos.
> 
> Thanks, done :)

Great!

> 
>> Do you think it's worth putting a Nix repository build for Mirage
>> into the cron-based builds so that we can spot when it breaks against
>> trunk?
> 
> I don't know. It could be a lot of wasted work since (I think) it
> should only really be breakable by buildscript changes, which I assume
> are pretty rare compared to code changes.
> 
> Right now opam2nix is just something I'm working on, but I'm hoping to
> roll it into nix proper one day - at which point I believe
> http://hydra.nixos.org/ may take care of detecting broken releases.
> That's probably good enough for a while, but certainly if mirage devs
> (who themselves might prefer working on trunk) want to make sure the
> nix expressions are always valid, we could look at setting up some
> trunk integration.

I'm not sure -- I don't use Nix myself, but I always feel that I ought
to be :-)  Does anyone else on the list use it day-to-day?

What granularity do you see opam2nix working at?  It should be fairly
easy to get individual switches running under Nix by setting OPAMROOT
appropriately, but individual package translation would be more work.
Edwin Torok started looking at similar issues for Deb/RPM on the
OPAM wiki at: https://github.com/ocaml/opam/wiki/opam2%7Brpm,deb%7D

If you have any design thoughts or notes on Nix integration, feel
free to edit that wiki...

>>> The main downside is that these changes make debugging a little
>>> trickier, since the build scripts are slightly more complex. Also, it
>>> might mean that a dependency could be picked up from a system package
>>> rather than from `opam`.
>>> 
>>> It may also be a better idea in general to just feed more information
>>> to the scripts directly from the `opam` file (via %{lib}% and friends)
>>> rather than have them assume too much about how they'll be installed.
>>> I didn't want to go down this route because it makes for more drastic
>>> changes, but I'm happy to try it if you're game.
>> 
>> There is an `opam-query` plugin which makes it easier to invoke from
>> shell scripts or Makefiles, so that it can be used as a default option
>> if an override isn't provided.  That might help...
> 
> Possibly, although the main knowledge required is "where is <x>
> dependency installed", and "where should _I_ install myself". I don't
> think `opam-query` will be able to resolve those kinds of questions,
> and it's probably cleaner to inject this information into command line
> arguments anyway, rather than the build script asking for it. opam2nix
> can act just like opam already for most interpolated variables
> (%{lib}% and friends), thanks to opam-lib - all that's needed is for
> the build script to accept this information on the command line, or in
> an env var.

Yep, agreed.  The intention behind opam-query is to provide a default
when OPAM is in use, but still make it easy to expose a Makefile variable
that can be overridden from the command line.

-anil


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