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

default_implementation should enforce public_name #2425

Closed
dra27 opened this issue Jul 18, 2019 · 1 comment · Fixed by #2558 or ocaml/opam-repository#14705
Closed

default_implementation should enforce public_name #2425

dra27 opened this issue Jul 18, 2019 · 1 comment · Fixed by #2558 or ocaml/opam-repository#14705

Comments

@dra27
Copy link
Member

dra27 commented Jul 18, 2019

I used the internal name of a library for default_implementation rather than the public_name. I initially didn't notice because the library was vendored, but did unexpectedly notice when I pinned the package in opam and built that way, since the dune-package file then contains a name which isn't in scope.

If the library referenced has a public_name, shouldn't Dune either insist on its being used in the default_implementation field or should it silently convert it to the public_name when it writes a dune-package file?

@ghost
Copy link

ghost commented Jul 18, 2019

To be consistent with the treatment of library dependencies, dune should silently convert the name

rgrinberg added a commit to rgrinberg/opam-repository that referenced this issue Aug 20, 2019
CHANGES:

- Remove the optimisation of passing `-nodynlink` for executalbes when
  not necessary. It seems to be breaking things (see ocaml/dune#2527, @diml)

- Fix invalid library names in `dune-package` files. Only public names should
  exist in such files. (ocaml/dune#2558, fix ocaml/dune#2425, @rgrinberg)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
1 participant