Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detection of ocamlnat is not robust enough if there are several installations of ocaml #33

Closed
jhjourdan opened this issue Feb 26, 2024 · 8 comments
Labels
enhancement New feature or request

Comments

@jhjourdan
Copy link

It seems like Down does not support OCaml 5. When I try to install it via opam, I get the following error message:

+ ocamlfind ocamlopt -c -g -bin-annot -safe-string -package compiler-libs.toplevel -I src -I test -o src/down_nattop.cmx src/down_nattop.ml
File "src/down_nattop.ml", line 6, characters 64-74:
6 | let () = if !Sys.interactive then (Down.Private.set_top (module Opttoploop))
                                                                    ^^^^^^^^^^
Error: Unbound module Opttoploop
Command exited with code 2.
+ ocamlfind ocamlopt unix.cmxa -I /home/jjourdan/.opam/4.14.0/lib/ocamlbuild /home/jjourdan/.opam/4.14.0/lib/ocamlbuild/ocamlbuildlib.cmxa -linkpkg myocamlbuild.ml /home/jjourdan/.opam/4.14.0/lib/ocamlbuild/ocamlbuild.cmx -o myocamlbuild
File "_none_", line 1:
Alert ocaml_deprecated_auto_include: 
OCaml's lib directory layout changed in 5.0. The unix subdirectory has been
automatically added to the search path, but you should add -I +unix to the
command-line to silence this alert (e.g. by adding unix to the list of
libraries in your dune file, or adding use_unix to your _tags file for
ocamlbuild, or using -package unix for ocamlfind).
pkg.ml: [ERROR] cmd ['ocamlbuild' '-use-ocamlfind' '-classic-display' '-j' '4' '-tag' 'debug'
     '-build-dir' '_build' 'opam' 'pkg/META' 'CHANGES.md' 'LICENSE.md'
     'README.md' 'src/down.a' 'src/down.cmxs' 'src/down.cmxa' 'src/down.cma'
     'src/down_top.cmx' 'src/down.cmx' 'src/down.cmi' 'src/down.mli'
     'src/down_std.cmx' 'src/down_tty_width.cmx' 'src/down_nattop.a'
     'src/down_nattop.cmxs' 'src/down_nattop.cmxa' 'src/down_nattop.cma'
     'src/down_nattop.cmx' 'src/down.cmx' 'src/down.cmi' 'src/down.mli'
     'src/down_std.cmx' 'src/down_tty_width.cmx' 'src/dlldown_stubs.so'
     'src/libdown_stubs.a' 'doc/index.mld' 'doc/manual.mld' 'src/down.top'
     'src/down.nattop']: exited with 10

(You can ignore the name of the switch "4.14.0": I'm recycling this switch but actually use OCaml 5.1.1 in it.

@dbuenzli
Copy link
Owner

That's a bit odd, no error is reported here.

Is this a switch with ocamlnat enabled ? There was some kind of changes upstream I think to minimize the differences between the toplevel, not sure if it affected down in some way.

@jhjourdan
Copy link
Author

This switch supports native compilation (i.e., it does have ocamlopt), but does not have an ocamlnat executable. How should I activate it via opam?

@dbuenzli
Copy link
Owner

No. But for some reason it seems that it tries to build the ocamlnat support which is the reason why it fails. The support is discovered via this. Are you sure you don't have ocamlnat in your PATH ?

@jhjourdan
Copy link
Author

Are you sure you don't have ocamlnat in your PATH ?

I do have another ocamlnat in my path. It comes from the OCaml installation of my system. You are right that if I hide it, then down installs correctly.

So, as far as I'm concerned, my problem is solved. But I'm leaving this issue open because the way ocamlnat is detected is not robust enough.

@jhjourdan jhjourdan changed the title Support for OCaml 5 Detetion of ocamlnat is not robust enough if there are several installations of ocaml Feb 26, 2024
@dbuenzli
Copy link
Owner

So, as far as I'm concerned, my problem is solved. But I'm leaving this issue open because the way ocamlnat is detected is not robust enough.

If you have something else to suggest why not. But if you ask me, in general having a mix of tools of the same toolchain from different installs in your PATH is definitively asking for trouble.

@dbuenzli dbuenzli added the enhancement New feature or request label Feb 26, 2024
@jhjourdan
Copy link
Author

Well, I never had a problem up to now. Also, with opam, this is a rather standard situation, I think.

An alternative detection mechanism could be to use which to search for the path of ocamlc, and then search for ocamlnat in the same path.

Anyway, feel free to close the issue if you consider you won't fix it.

@dbuenzli
Copy link
Owner

dbuenzli commented Feb 26, 2024

Well, I never had a problem up to now. Also, with opam, this is a rather standard situation, I think.

It is definitively standard problems.

E.g. your system ocamlfind is being used with your switch compiler because your switch has no ocamlfind installed. On macos people constantly run into problems because they install alternate C compilers or even another uname with brew or macports which makes their OCaml install explode.

And the day we will have a combination of cross-compilation and byte-code or native-code only switches, everything will simply melt-down :-)

The problem is a bit more general here and I'm not sure it's necessarily the best idea to try to solve the problem at the package level.

@dbuenzli dbuenzli changed the title Detetion of ocamlnat is not robust enough if there are several installations of ocaml Detection of ocamlnat is not robust enough if there are several installations of ocaml Feb 27, 2024
@dbuenzli
Copy link
Owner

dbuenzli commented May 8, 2024

It seems I have missed the sanitization of the ocamlnat toploop API upstream made in ocaml/ocaml#10061.

Not only does it drastically simplify down's build and implementation. It also means we no longer have to probe for ocamlnat.

So… problem solved! And thanks @AltGr for the upstream work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants