Since this is the final step this will likely not entail failures like #77. But it could lead to corrupted outputs. This is due the flat nature of the driving bits. I guess this can now be solved with odoc 3. Need to review what the doc says about the new driving interface.
Example repro:
> opam pin add negsp https://erratique.ch/repos/negsp.git
> odig doc -u
> odig log --diagnosis
Error: Found 9 problems
File '/Users/dbuenzli/.opam/5.3.0/var/cache/odig/html/negsp/Negsp/Border/index.html'
is written by more than one operation:
[9094:spawn 2.51ms negsp r:00e01ac7100f70a3] ['/Users/dbuenzli/.opam/5.3.0/bin/odoc' 'html' '--theme-uri' '_odoc-theme' '-o' '/Users/dbuenzli/.opam/5.3.0/var/cache/odig/html' '/Users/dbuenzli/.opam/5.3.0/var/cache/odig/odoc/negsp/brr/negsp.odoc' '-I' '/Users/dbuenzli/.opam/5.3.0/var/cache/odig/odoc/brr/' '-I' '/Users/dbuenzli/.opam/5.3.0/var/cache/odig/odoc/htmlit/' '-I' '/Users/dbuenzli/.opam/5.3.0/var/cache/odig/odoc/negsp/' '-I' '/Users/dbuenzli/.opam/5.3.0/var/cache/odig/odoc/negsp/assets/' '-I' '/Users/dbuenzli/.opam/5.3.0/var/cache/odig/odoc/negsp/brr/' '-I' '/Users/dbuenzli/.opam/5.3.0/var/cache/odig/odoc/negsp/htmlit/' '-I' '/Users/dbuenzli/.opam/5.3.0/var/cache/odig/odoc/ocaml/'][0]
[9100:spawn 2.05ms negsp r:8be791acdba1db34] ['/Users/dbuenzli/.opam/5.3.0/bin/odoc' 'html' '--theme-uri' '_odoc-theme' '-o' '/Users/dbuenzli/.opam/5.3.0/var/cache/odig/html' '/Users/dbuenzli/.opam/5.3.0/var/cache/odig/odoc/negsp/htmlit/negsp.odoc' '-I' '/Users/dbuenzli/.opam/5.3.0/var/cache/odig/odoc/brr/' '-I' '/Users/dbuenzli/.opam/5.3.0/var/cache/odig/odoc/htmlit/' '-I' '/Users/dbuenzli/.opam/5.3.0/var/cache/odig/odoc/negsp/' '-I' '/Users/dbuenzli/.opam/5.3.0/var/cache/odig/odoc/negsp/assets/' '-I' '/Users/dbuenzli/.opam/5.3.0/var/cache/odig/odoc/negsp/brr/' '-I' '/Users/dbuenzli/.opam/5.3.0/var/cache/odig/odoc/negsp/htmlit/' '-I' '/Users/dbuenzli/.opam/5.3.0/var/cache/odig/odoc/ocaml/'][0]
[…]
Since this is the final step this will likely not entail failures like #77. But it could lead to corrupted outputs. This is due the flat nature of the driving bits. I guess this can now be solved with
odoc3. Need to review what the doc says about the new driving interface.Example repro: