Out of curiosity, do we have a pointer to the "relocation patch" and its upstreaming discussion? If some upstream changes can be made to make binary distribution easier, we could try to push them.
(If I understand https://github.com/ocaml/opam-repository/blob/master/compilers/4.02.3/4.02.3%2Bmusl%2Bstatic/4.02.3%2Bmusl%2Bstatic.comp correctly, the upstream compiler needs no patching to work with musl.) On Fri, Jan 22, 2016 at 8:53 AM, Anil Madhavapeddy <[email protected]> wrote: > On 22 Jan 2016, at 05:47, Louis Gesbert <[email protected]> > wrote: > > > > Le vendredi 22 janvier 2016, 08:34:34 Gabriel Scherer a écrit : > >> I would be interested in some more information on this. This seems very > >> simple as you say it, but I had not thought about the fact that OPAM > >> already has the capacities to act as a binary distribution platform -- I > >> somehow thought that there would be an announcement of some new extra > >> features at some point designed for binary distribution. > >> > >> Louis, you are saying that this is feasible. Are you aware of this > actually > >> having been done? For example, is anyone working on providing a, say, > opam > >> repository for x86-64 binaries corresponding to the packages available > on > >> opam-repository? > >> > >> I suppose that if people proposed that, they would probably pre-build > >> binaries for only a subset of the possible packages or configurations. > >> Would it work to mix a "binary repository" that provides only a subset > of > >> the packages, and the official source repository, and would package > query > >> solvers have a way to do the right thing there? Or would it be the > >> responsibility of the alternate repository provider to include a > >> source-only fallback for the non-distributed packages? (This would make > it > >> harder to have a single repository with binary packages for several > >> architectures.) > > > > `ocp-bin` was an experiment to provide such a cache of pre-built > packages, > > falling back to building from source when unavailable for the current > setup. > > With the official OCaml distribution, you would hit issues of relocation > > though, although there are some hacks around that > > (https://github.com/OCamlPro/ocp-reloc) > > > > So although there are no real barriers in Opam for a binary repository, > doing > > something like a conversion from source repo to binary repo, especially > with > > OCaml, raises some challenges. > > How about an OPAM switch that uses the compiler relocation patch and musl > libc and the right CFLAGS to link everything statically by default? That > should provide an experience similar to Go, with an output binary that is > standalone (including libc). > > Anil > >
_______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
