If your package manager is not able to devise consistent environments as unix prefixes, then I’d rather suggest something is wrong with it. A lot of things work that way, starting with PATH in your shell so you’d rather cater for it. But in any case you can always extend your environment on the cli and the compiler supports response files.
Well as a matter of fact ocamlfind is doing your env magic. But in any case I don’t see what in the RFC prevents ocamlfind to continue doing it for you. The RFC doesn’t break ocamlfind.
I’m not sure I fully understand what you are saying here.
But I think it should be stressed that the proposal affects more than the compiler. The proposal is about the OCaml system. It also affects the toplevel, Dynlink and regularizes library installs which can be insanely flexible and is problematic for build-system dependency tracking.
It also tries to cut on the moving part and concepts in the system whose cruft is always embarrassing to explain to newcomers.
It should also be stressed again that this is totally compatible with ocamlfind as it exists.
Personally I think it would be an error to “ossify” as you say on dune which I don’t see as the final word on build systems.
Note that the RFC itself is not breaking anyone’s worfklow, it’s precisely devised so that the whole eco-system continues working without needing to change anything. If someone is breaking your workflow here it seems to be dune which apparently no longer wants to support findlib.conf.
I’m more than happy to shift it in the right direction. But so far I haven’t found out from what you are saying:
- What is wrong exactly.
- What the right direction is.