Le mardi, 13 octobre 2015 à 11:23, Thomas Gazagnaire a écrit : > One thing what I'd like is the system to stay simple when people don't use > cross-compilation.
I would put it differently. We don't want to bother people with cross-compilation if they don't need to be, which is slightly different. As mentioned in my last message the goal is to avoid to have to maintain separate repositories for cross compilation so from the package repository point of view (i.e. package files) there should be no such thing as people who 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. This is actually mentioned in the proposal but your thinking is wrong: non prefixed variable must have host semantics — host is the thing you install, e.g. the variable lib should be equal to host-lib. > 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`. Well it can simply ask for confirmation. I think we should avoid a discrepancy between what `opam switch arch list` tells you and install reality (see below). > 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. I disagree. I want to be able to treat the switch as an entity regardless of architecture so that a `PKG:installed` variable is `true` iff it is installed in all architecture. If you don't do this then you need to be able to introduce architecture specifiers in variables (e.g. PKG:$(ARCH):installed) which I think we should avoid. Best, Daniel _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
