On 2014-12-21 14:28, Thomas Gazagnaire wrote:
Hi,
- Allow **direct use of more solvers** or solver servers.
If we go this route I really would like to have a proper `opam solver`
command (similar to `opam repo` or `opam pin`).
- **Support cross-compilation**
This is quite an open issue at the moment.
This needs support on the build system side, so I'm not sure it's a
high priority for now on (although it would be *very* nice to have at
one point).
Something which would be a bit simpler but very still very useful is
to share things between switches: ie. you want to use install things
in one switch while using things installed in other ones. Could be
used to cross-compile (host / target) but also to have a base ocaml
installation with "layers" of different packages (so need to recompile
the compiler every-time). Don't have a clear spec of that yet, though.
I completely agree; this is how opam-android essentially works now.
https://github.com/whitequark/opam-android/
It still needs per-package tweaks, so I'm not sure it could be
automated.
An other idea related to that: better support for global installation
where it would be cool to have some (OCaml) packages installed on the
system which are "external" i.e. not managed by opam (so a fixed
package version which is not removable). Think mixing both `apt-get
install` and `opam install foo`. I guess that's also related to the
'compiler-as-a-package" stuff ...
That would only work for binaries. I'm not sure how useful would it be.
Having a way to have
multiple versions of the same library installed in the same switch
could be very cool as well, although again it requires support in
ocamlfind/build systems and it will break quite a few assumptions in
opam so it won't be very easy to add properly.
This is an extremely bad idea. It has been tried in RubyGems;
the conclusion of both users and maintainers is that it should have
never been added. The main problem is what happens when there are
many disjoint ranges of possible versions for some package:
the behavior gets very unexpected.
--
Peter Zotov
_______________________________________________
opam-devel mailing list
[email protected]
http://lists.ocaml.org/listinfo/opam-devel
