Dear Dune devs, I'm seeing this when working under trunk:
$ make release
./boot.exe --release
ocamlc src/dune_lang/.dune_lang.objs/byte/dune_lang.{cmi,cmti} (exit 2)
(cd _build_bootstrap/default && /home/egallego/.opam/4.09.0+trunk/bin/ocamlc.opt -w -40 -g -bin-annot -I src/dune_lang/.dune_lang.objs/byte -I src/stdune/.stdune.objs/byte -I src/stdune/.stdune.objs/native -no-alias-deps -open Dune_lang__ -o src/dune_lang/.dune_lang.objs/byte/dune_lang.cmi -c -intf src/dune_lang/dune_lang.mli)
File "src/dune_lang/dune_lang.mli", line 18, characters 18-26:
18 | val of_digest : Digest.t -> t
^^^^^^^^
Error: Unbound type constructor Digest.t
-> required by src/dune_lang/.dune_lang.objs/byte/dune_lang.cmi
-> required by alias src/dune_lang/lib-dune._dune_lang.cmi-all
-> required by alias src/dune_lang/lib-dune._dune_lang.cmi-and-.cmx-all
-> required by bin/.main.objs/native/main.cmx
-> required by bin/main.a
-> required by bin/main_dune.exe
-> required by _build_bootstrap/install/default/bin/dune
-> required by dune.install
Thus Dune fails to build. I am not sure if action on Dune part should be taken, but submitting an issue so at least the potential problem is tracked.
What happens if you replace this by Stdune.Digest.t?
Same @diml
Hmmm, I have a feeling this is related to ocaml/ocaml#2041. However, I'm not sure how. Maybe it's an issue with the build of the stdune library itself, this needs to be investigated
never mind
That's the build log https://pastebin.com/kA5WKDV9
Ah, it's blocked by the proxy, could you copy&paste the interesting lines?
File attached.
log.zip
Could you run ocamlobjinfo on stdune.cmi?
Another thing to try: instead of Stdune.Digest.t, use Stdune__Digest.t
egallego@lasserre:~/external/dune/_build_bootstrap/default/src/stdune/.stdune.objs/byte$ ocamlobjinfo stdune.cmi
File stdune.cmi
Unit name: Stdune
Interfaces imported:
f92de6d4971cf4200df7a0205974a36a Stdune
3fcc2ab48349d9139a4a96d35d27054d Stdune__Result
ae883c9313c685a60b3d4618007f5c35 Stdune__Ordering
89020e47d5a40814cc00b8f06e8ee7fd Stdune__Either
33ce98ecfa5f35f2d32148491f2d27bc Stdune__
dc3ce4703cbd5d02ac83733c46a7aa29 Stdlib__uchar
036ff28e1e61113ecbbc42d3235d943e Stdlib__set
c7e3f663a204898012b529882aa58709 Stdlib__seq
6a5b6feacf7d0249bf88ce9571fa6017 Stdlib__printf
d65d46ceb8f94612d84c2b5795c6e8bc Stdlib__pervasives
31a92110686b77f37ab6d2bb75a10f13 Stdlib__moreLabels
f47f05bd1e0c4d146ae6765614a1bab3 Stdlib__map
d4658e83059de33ae4891867b6f1b421 Stdlib__hashtbl
cd51d9da400091030a109b657ed989eb Stdlib__buffer
ce2c28335845df632ca4efc132525f3d Stdlib
0193c44ec2560466bfdf4045fb227d6e Dune_caml__Result_compat
0af54d4c07314a60140dc4a8c24d2396 Dune_caml__Result
0a61929e25fb84d3d4996fcd917d60b8 Dune_caml__
7d8fe4804c8d8222b2c89d2682cf59f9 Dune_caml
741eeb27cd760b6e28cafef4c771ec24 CamlinternalFormatBasics
This looks the same as with 4.07. What about stdune__.cmi?
I'd say it seems fine too.
I installed a trunk compiler. If I use Stdune.Digest.t, compilation fails with Unbound type constructor .... If I do instead:
module S = Stdune
...
val of_digest : S.Digest.t -> t
then it passes. I have seen a similar error while working on ocaml/ocaml#2041. I'm having another look at the compiler code.
Ah, I get it... The order of -I is now relevant and should be topologically sorted, currently we alphabetically sort include paths.
Wait no, that's not it at all. Re-reading the compiler code, the problem is indeed because Stdune__Digest doesn't appear in the output of ocamlobjinfo ... stdune.cmi: because of that, it is not considered as a persistent module when loading stdune.cmi.
Fixed by ocaml/ocaml#2235
Fix confirmed! make release works again; dev mode will need a bit more of work.