How do you pull in mirage-entropy-xen? It does not appear in the opam file at all. I think you could just optionally depend on mirage-xen-entropy which already depends on mirage-xen. I have no idea how to have conjonctive depopts anymore (/cc @AltGr who removed my beautiful hack which did that in old version of opam :p)

there aren't dependencies depending on optional dependencies, see also ocaml/opam#2074

I think you could just optionally depend on mirage-xen-entropy which already depends on mirage-xen

Actually scratch that, this is wrong. I need to think of a better solution.

while this is not nice and clean, I thought the mirage tool would dependency-inject mirage-entropy-xen if nocrypto is in use (nocrypto needs an optional dependency to mirage-entropy-xen, then it'll be recompiled after installation of mirage-entropy-xen)

So now if mirage-entropy-xen is installed by default when using mirage+xen, you should also optionally depend on mirage-entropy-xen in the opam file (and you can remove the dependency to mirage-xen). That should fix Travis CI (and you'll need to modify https://github.com/mirleft/ocaml-nocrypto/blob/master/.travis-ci.sh#L28 as well or use the Travis CI skeletons).

@samoht Yes, well, I prefer no features to features that mostly work in practice :) (actually, it might have really worked, but the proof is really unclear)

Note, to be fair, that we can have conjunctions in depopts again. I removed them, because I was not sure it was really useful and changing the semantics of something that was already used seemed like a bad idea. Actually, not even removed: only forbid in 1.2 (please don't declare packages with opam-version 1.1 just to use it though ! ;))

The effect of a conjunction would be to ignore recompilations of packages in it if it's only partially verified. Now I'm not sure I understand the whole of the use-case :)

only forbid in 1.2 (please don't declare packages with opam-version 1.1 just to use it though ! ;))

please don't declare packages with opam-version 1.1 just to use it though ! ;))

use it though! ;))

The cat's out of the box now.

Now I'm not sure I understand the whole of the use-case :)

This library either depends on two packages, the core xen and the xen entropy provider, or none of those (and it doesn't build the xen support).

Level 1 would be to discover them as a pair and somehow signal to the configure script that both are present, or hide the other one if either is missing.

Level 2 is to detect that xen is installed and add the dependency to entropy, as opposed to not using it until the user installs both. That would be ideal.

Ok.

Level 1: For the configure script, you can use the syntax "%{mirage-xen+mirage-entropy-xen:installed}%" ; or the new features field to define a "variable" that you can use in there.

Level 2: the problem is in the detection -- since mirage-xen can be pulled in the same command as your lib, this would need to be encoded to the solver. That could become problematic, too: imagine if for some reason mirage-entropy-xen cannot be installed, then the library could only be installed if you don't have mirage-xen. The error would be difficult to explain to the user, too.

@AltGr I was joking, I know that my hack my unsafe in the presence of version constraints and so removing it was the good move.

The problem we have here is to decide who will pull in the mirage-entropy-xen (or gmp-xen or zlib-xen) optional dependency: currently mirage configure --xen triggers the installation of mirage-xen which is supposed to enable all the xen "features" in the different packages. But if the xen feature or nocrypto depends optionally on mirage-xen and X, so X should be pulled in as well and ideally not by mirage as we will need to keep track on all the optional requirements in the tool ...

@AltGr Level 1 solution looks very nice, as it will at least prevent builds from breaking. Will add, thank you.