Odoc: valid module name clashes cause issues

[jonludlam]

It's perfectly valid to have a dune project containing sub-libraries that have unwrapped modules with the same name. For example:

one/names.ml
two/names.ml

Where the public-name for these is e.g. repro.one and repro.two. These libraries can't be linked together, but the documentation should be able to coexist. Currently this is not possible as odoc is producing the same html filename for both modules:

Multiple rules generated for _build/default/_doc/_html/repro/Names/index.html:
- <internal location>
- <internal location>

[ghost]

Hmm yh, I believe it's because odoc works with packages rather than libraries. I don't know how we can fix this in Dune :/

[jonludlam]

I've updated the description to make it clear that this is for sub-libraries (repro.one and repro.two)

[jonludlam]

This is related to ocaml/odoc#148

[ejgallego]

Indeed only workaround so far is to wrap one of the libs and set -open Lib in the corresponding Dune flags.

[avsm]

I'm still seeing this in yallop/ocaml-ctypes#588 with odoc 1.4.0, need to investigate more:

 $ dune build @doc
Error: Conflicting implementations for virtual library "ctypes-foreign":
- "ctypes-foreign.threaded" in _build/default/src/ctypes-foreign-threaded
- "ctypes-foreign.unthreaded" in _build/default/src/ctypes-foreign-unthreaded
Multiple rules generated for _build/default/_doc/_html/ctypes-foreign/Foreign/index.html:
- <internal location>
- <internal location>

[rgrinberg]

@jonludlam is there a corresponding odoc bug? I don't think this can be fixed until odoc addresses this.

[jonludlam]

@avsm which version of dune are you using? This ought to be addressed by #2141

@rgrinberg there's no issue on the odoc repo yet. I'll make one when I've got a moment.

[avsm]

@jonludlam twas with the released dune 1.9.3 -- I'll try with the master branch shortly

[davesnx]

Facing this issue and found ocaml/odoc#148 has been resolved. Is there any chance to relook into this?

[Khady]

Is it correct to say that this is (at least partially) fixed by the @doc-new rule?

[emillon]

ping @jonludlam for this question
(though I wouldn't close issues fixed by doc-new until we know how these new rules are going to be enabled)

[jonludlam]

Yes, doc-new should not have this problem. See the test cases for doc rules and doc-new rules