ocaml / dune

A composable build system for OCaml.
https://dune.build/
MIT License
1.63k stars 402 forks source link

Dependency cycle when building the `lwt` project with dune package management #10839

Closed gridbugs closed 1 week ago

gridbugs commented 2 months ago

To reproduce, run:

$ opam source lwt.5.7.0
$ cd lwt.5.7.0
$ dune pkg lock
$ DUNE_CONFIG__TOOLCHAINS=enabled dune build
Error: Dependency cycle between:
   - package base-bytes
-> _build/_private/default/.pkg/ocamlfind/target/cookie
-> - package base-bytes

There's no obvious dependency cycle between lockfiles. Projects that depend on lwt build fine with dune package management. This problem only happens when building the lwt project itself.

I'll update this issue as I find more projects with this problem.

rgrinberg commented 2 months ago

I got a different cycle by following your steps:

Dependency cycle between:
   - package react
-> _build/_private/default/.pkg/ocamlfind/target/cookie
-> - package topkg
-> - package react
Leonidas-from-XIV commented 2 months ago

I get this when I replace ocaml with ocaml-system, lock and try to build:

Error: Dependency cycle between:    
   - package base-bytes
-> _build/_private/default/.pkg/ocamlfind/target/cookie
-> - package base-bytes

It looks like the dependency is introduced via ocplib-endian which in turn depends on base-bytes and base-bytes depends on ocamlfind. But ocamlfind in our lock directory does not depend on base-bytes. It seems somehow we accidentally introduce an incorrect dependency to ocamlfind (which only depends on ocaml and is correctly locked that way).

Leonidas-from-XIV commented 1 month ago

After removing the ocamlfind dependency from base-bytes I got the same error as Rudi:

Error: Dependency cycle between:
   - package react
-> _build/_private/default/.pkg/ocamlfind/target/cookie
-> - package topkg
-> - package react

The only other dependencies on ocamlfind are topkg and react (which depends on ocamlfind and topkg) and removing them unlocks the dependency cycle but fails to build. It seems there's something weird about ocamlfind, but we don't special-case it in the package rule code and the lock result looks totally correct.