On 30/06/2016 17:09, Fabrice Le Fessant wrote:
The reason why OPAM-builder cannot monitor trunk is by design: to achieve almost real time on a 4-core computer for 5 versions of OCaml, opam-builder makes an extensive use of caching binary installations of dependencies. This cannot be done on a moving target like trunk, where you would have to recompile all packages (all versions, sometimes with different depends because of depopts) at every commit in the trunk, after clearing the cache. That's the reason why I only do it for official beta releases, and opam-builder takes two or three days to compile the repo.
Testing only the latest version of each package would already be very useful. As a matter of fact, it could even detect earlier some problems by restricting the universe only to latest version of all packages (see below).
Moreover, it could be interesting to define a subset of "strategic" packages that we should really be up-to-date on OCaml release dates. Wasn't it part of the "platform" project to define such a curated list of packages?
Do you have a description of OPAM-builder current strategy? I found out yesterday that a simple "opam install ppx_type_conv" would fail on a clean 4.03 switch, because the latest version of that package compatible with 4.03 depends on ppx_deriving with no upper bound constraint, and OPAM chooses to install the latest version of ppx_deriving which turns out to be incompatible with that version of ppx_type_conv. But OPAM-builder did not report any error for that version of ppx_type_conv: it picked an older version of ppx_deriving (which works fine). I'm wondering if this is because of a different solver configuration, or a deliberate (or not) consequence of OPAM-builder strategy.
Alain _______________________________________________ Platform mailing list [email protected] http://lists.ocaml.org/listinfo/platform
