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

topdirs.cmi multiple locations #6754

Open
vicuna opened this issue Jan 19, 2015 · 15 comments
Open

topdirs.cmi multiple locations #6754

vicuna opened this issue Jan 19, 2015 · 15 comments

Comments

@vicuna
Copy link

@vicuna vicuna commented Jan 19, 2015

Original bug ID: 6754
Reporter: @ygrek
Status: acknowledged (set by @damiendoligez on 2015-02-06T17:43:54Z)
Resolution: open
Priority: normal
Severity: minor
Version: 4.02.1
Target version: 4.07.0+dev/beta2/rc1/rc2
Category: standard library
Monitored by: kandu @hhugo @whitequark @gasche @rixed @yallop @hcarty @mmottl

Bug description

$ find /home/ygrek/.opam/4.02.1/lib/ocaml| grep topdirs.cmi
/home/ygrek/.opam/4.02.1/lib/ocaml/compiler-libs/topdirs.cmi
/home/ygrek/.opam/4.02.1/lib/ocaml/topdirs.cmi

and every invocation of compiler referencing compiler-libs results in ocamlfind warning

findlib: [WARNING] Interface topdirs.cmi occurs in several directories: /home/ygrek/.opam/4.02.1/lib/ocaml/compiler-libs, /home/ygrek/.opam/4.02.1/lib/ocaml

The md5 sum of both modules is the same. I wonder what would be the best way to remove this warning - either the OCaml distribution should install it only in one place or ocamlfind should check md5 and not report it as duplicate because whichever is used will not matter?

@vicuna
Copy link
Author

@vicuna vicuna commented Jan 19, 2015

Comment author: @whitequark

Special-casing the md5 in ocamlfind is of course not the answer. It's not even stable between builds of ocaml.

Why can't topdirs.cmi be installed only in lib/ocaml, anyway?

@vicuna
Copy link
Author

@vicuna vicuna commented Jan 19, 2015

Comment author: @ygrek

I mean that once ocamlfind detects same cmi occuring in multiple dirs it could check the md5 of those cmi and if they all are equal - it means interfaces are really equal.
But I agree that installing in only one location would be the best solution.

@vicuna
Copy link
Author

@vicuna vicuna commented Feb 6, 2015

Comment author: @damiendoligez

Interesting. My first reaction was put it into lib/ocaml/compiler-libs, where you also find toploop, topmain, and topstart. @whitequark, do you have any particular reason to want it in lib/ocaml ?

@vicuna
Copy link
Author

@vicuna vicuna commented Feb 6, 2015

Comment author: @whitequark

I thought topfind uses Topdirs but I now see that it does #directory "+compiler-libs" so that doesn't matter anyway.

@vicuna
Copy link
Author

@vicuna vicuna commented Jul 23, 2015

Comment author: @hcarty

Is it safe to move/remove lib/ocaml/topdirs.cmi? Anything using ppx_blob, for example, generates lots of findlib warnings.

Moving that file and adding '#directory "+compiler-libs";;' to my ~/.ocamlinit allowed utop to work and code to compile without the findlib warnings.

@vicuna
Copy link
Author

@vicuna vicuna commented Jul 23, 2015

Comment author: @whitequark

@doligez, right, hcarty's comment above is why I wanted it in lib/ocaml, I think

@vicuna
Copy link
Author

@vicuna vicuna commented Dec 1, 2015

Comment author: @hhugo

Any chance to see this resolved for 4.03 ?

@vicuna
Copy link
Author

@vicuna vicuna commented Jan 5, 2016

Comment author: @johnwhitington

This warning is, by default, fatal to ocamlmktop, so one has to do "-warn-error -31" if making a custom top level with compiler-libs.

Does anyone know why warning 31 should be fatal for ocamlmktop but not ocamlc?

@vicuna
Copy link
Author

@vicuna vicuna commented Jan 13, 2016

Comment author: pveber

Removing lib/ocaml/topdirs.cmi seems the cleanest solution to me. For the record, this would require some adjustments in opam (for the generated .ocamlinit) and oasis (the generated setup.ml file in dynamic update mode) and maybe other libs. Before doing anything, it would wiser I think to announce/discuss it on the list, so that everybody can think and report on the possible implications.

In any case, it would be great to fix this. I can provide some help if needed.

@vicuna
Copy link
Author

@vicuna vicuna commented Apr 17, 2016

Comment author: @gasche

We missed the timeline for 4.03 on this one. If someone (Philippe included) is willing to take action on this issue (starting a mailing-list discussion etc.), now would be an excellent time, so that we get a change early in the 4.04+dev lifetime.

@vicuna vicuna added the stdlib label Mar 14, 2019
@vicuna vicuna added this to the 4.07.0 milestone Mar 14, 2019
@vicuna vicuna added the bug label Mar 20, 2019
@olafhering
Copy link
Contributor

@olafhering olafhering commented Nov 18, 2019

@nojb
Copy link
Contributor

@nojb nojb commented Jun 17, 2020

Anyone knows what is the status of this? It appears it is still the case that topdirs.cmi is installed twice in the installation directory and I was wondering if there was a specific reason for this?

@gasche
Copy link
Member

@gasche gasche commented Jun 17, 2020

I think that the two copies were left around for compatibility (originally it was just in ocaml, and when we introduced ocaml/compiler-libs it was also installed there). As the discussion above shows, it's not completely obvious to decide which of the two places should be favored. I may be fine to remove today the ocaml/topdirs.cmi copy; it may break stuff, but the +compiler-libs fix is backward-compatible with all recent-enough versions of OCaml (which was not the case originally).

@nojb
Copy link
Contributor

@nojb nojb commented Jun 22, 2020

I may be fine to remove today the ocaml/topdirs.cmi copy; it may break stuff, but the +compiler-libs fix is backward-compatible with all recent-enough versions of OCaml (which was not the case originally).

Thanks; an even better solutions would be provided by #9056 as we can make just the one file visible to the compiler, see #5628.

@github-actions
Copy link

@github-actions github-actions bot commented Jun 25, 2021

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label Jun 25, 2021
@damiendoligez damiendoligez removed this from the 4.07.0 milestone Jul 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants