search

fdopen / opam-repository-mingw

windows package repository for OPAM (mingw and msvc)
https://fdopen.github.io/opam-repository-mingw/
Creative Commons Zero v1.0 Universal
96 stars 33 forks source link

Add ocaml-secondary-compiler and ocamlfind-secondary #75

Open smorimoto opened 4 years ago

smorimoto commented 4 years ago

I don't know much about Windows, is there any technical problem?

fdopen commented 4 years ago

The repo is probably most commonly used within CIs. OCaml isn't usually compiled from source, but a binary version is fetched to speed it up.

Normally, the compiler would only work, if it is available at the same location that was specified at compile time. The OCAMLLIB environment variable is used to workaround this limitation. But this variable would then be picked up by the secondary compiler, too - which would be wrong.

It would be necessary to add additional logic to the ocaml-secondary-compiler package, to remove or override this enviroment variable somehow. I was too lazy to implement this. Instead I've added binary packages of dune for older OCaml versions (dune is currently the only package that references ocaml-secondary-compiler).

Et7f3 commented 4 years ago

env -u OCAMLLIB could do the tricks https://github.com/esy-ocaml/esy-opam-override/blob/6/packages/ocaml-secondary-compiler.4.08.1-1/package.json#L7-L9

fdopen commented 3 years ago

env -u OCAMLLIB could do the tricks

Yes, it should work during the compilation of ocaml-secondary-compiler. But what if the compiler is used later? Wouldn't it pick up OCAMLLIB from the environment then?

Et7f3 commented 3 years ago

It will pick the OCAMLLIB from environnement so end user should set it. https://github.com/esy-ocaml/esy-opam-override/blob/6/packages/dune.2.7.1/package.json#L6 I think it ok because mostly only dune require the secondary compiler and OCAMLLIB coup then be keept for the primary compiler.