The proposal looks fine to me. One thing what I'd like is the system to stay simple when people don't use cross-compilation. That might mean maybe renaming `build-os` to `os` so that things stays as they are when build-os = host-os = os. Could also mean that `build-prefix` is a special case and don't contains the `<arch>` suffix.
About the automatic installation of packages when adding a new architecture to the switch: I'm not very found of that. I usually misspell my `git remote add` commands and I'm happy to have `git remote set-url` and `git fetch` as separate commands. So maybe in this case, just lazily install the missing packages for the new arch on `opam upgrade` and `opam install`. So I think that the constraint: "all installed packages should have the same version for all the architectures" is fine, but the constraint "all installed packages should be installed on all architectures" is too strong. So maybe you want `opam install --arch`. Thomas > On 13 Oct 2015, at 01:31, Daniel Bünzli <[email protected]> wrote: > > Hello, > > I started to write down a few ideas for supporting multiple architecture > (i.e. cross-compilation) in opam. It's far from complete, glosses over many > details and maybe too simplistic — but I have the feeling that it's better to > try to keep things simple in that setting. > > I will certainly not be the person who can fill in all the details — > especially on how to solve and resolve dependencies, I'm sure the solver > experts have a better idea of what is needed here than what I'm proposing. > People who are familiar with `apt` multi-architecture support may also be in > a better position to design this. > > So I just dumped my broken set of ideas on the opam wiki so that people can > help to improve it and bring it to a full proposal: > > https://github.com/ocaml/opam/wiki/opam-multiarch > > Feedback and discussion about the general approach is better done on this > list I think. And this should start with whether the support should be > handled as an inter or intra switch feature; this proposal being the latter > (for these reasons [1]). I know there were attempts at the former so it would > be nice if we could reach consensus on this first. > > Best, > > Daniel > > [1] https://github.com/ocaml/opam/wiki/opam-multiarch#alternative-designs > > > > > > _______________________________________________ > opam-devel mailing list > [email protected] > http://lists.ocaml.org/listinfo/opam-devel _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
