This commit is contained in:
swrup 2025-11-11 02:07:51 +01:00
parent aa2ff7b2f0
commit 2f3113f55d
11742 changed files with 1223940 additions and 0 deletions

View file

@ -0,0 +1,80 @@
This test demonstrate a dependency cycle if we consider nodes as modules, but a
valid dependency graph if we consider the implementations and interfaces of
modules as having separate dependencies.
Reproduces #7018
$ cat >dune-project <<EOF
> (lang dune 3.7)
> EOF
$ cat >dune <<EOF
> (library
> (wrapped false)
> (name foobar))
> EOF
$ cat >x.mli <<EOF
> type t = unit
> EOF
$ cat >y.mli <<EOF
> val foo : X.t -> unit
> EOF
$ cat >y.ml <<EOF
> let foo _ = ()
> EOF
$ runtest() {
> cat >x.ml <<EOF
> type t = unit
> let () = Y.foo $1
> EOF
> dune build
> }
First we try to construct X.t directly
$ runtest "()"
Error: dependency cycle between modules in _build/default:
X
-> X
-> required by _build/default/foobar.a
-> required by alias all
-> required by alias default
File "x.ml", line 2, characters 15-17:
2 | let () = Y.foo ()
^^
Error: The constructor () has type t but an expression was expected of type
X.t
Type X.t is abstract because no corresponding cmi file was found
in path.
[1]
Now we use a polymorphic type:
$ runtest "(assert false)"
Error: dependency cycle between modules in _build/default:
X
-> X
-> required by _build/default/foobar.a
-> required by alias all
-> required by alias default
[1]
Or, we can use another module:
$ cat > unit.ml <<EOF
> let x = ()
> EOF
$ cat > unit.mli <<EOF
> val x : X.t
> EOF
$ runtest "Unit.x"
Error: dependency cycle between modules in _build/default:
X
-> X
-> required by _build/default/foobar.a
-> required by alias all
-> required by alias default
[1]

View file

@ -0,0 +1,18 @@
We don't need to run ocamldep on ther alias module
$ cat >dune-project <<EOF
> (lang dune 3.19)
> EOF
$ cat >dune <<EOF
> (library
> (name foo))
> EOF
$ touch bar.ml
$ dune build foo.cma
$ find _build -iname "*.d" -o -iname "*.all-deps" | sort
_build/default/.foo.objs/foo__Bar.impl.all-deps
_build/default/.foo.objs/foo__Bar.impl.d

View file

@ -0,0 +1,78 @@
Dune uses ocamldep to prevent a module from depending on itself.
$ cat >dune-project <<EOF
> (lang dune 2.8)
> (wrapped_executables false)
> EOF
$ mkdir lib
$ cat >lib/dune <<EOF
> (library
> (name foo))
> EOF
$ cat >lib/bar.ml <<EOF
> Foo.bar
> EOF
$ dune build @all
Error: Module Bar in directory _build/default/lib depends on Foo.
This doesn't make sense to me.
Foo is the main module of the library and is the only module exposed outside
of the library. Consequently, it should be the one depending on all the other
modules in the library.
-> required by _build/default/lib/.foo.objs/foo__Bar.impl.all-deps
-> required by _build/default/lib/.foo.objs/byte/foo__Bar.cmo
-> required by _build/default/lib/foo.cma
-> required by alias lib/all
[1]
$ rm lib/bar.ml
This check doesn't apply to single module libraries:
$ cat >lib/foo.ml <<EOF
> let x = Foo.x
> EOF
$ dune build @all
File "lib/foo.ml", line 1, characters 8-13:
1 | let x = Foo.x
^^^^^
Error: Unbound module Foo
[1]
$ rm lib/foo.ml
However, we'll demonstrate that this check isn't applicable to executables:
$ cat >lib/bar.ml <<EOF
> let run () = print_endline "Hello World"
> EOF
$ mkdir exe
$ cat >exe/dune <<EOF
> (executable
> (name foo)
> (libraries foo))
> EOF
$ cat >exe/foo.ml <<EOF
> Foo.Bar.run ();;
> EOF
Although we get slightly different behavior if wrapping is on or off:
$ cat >dune-project <<EOF
> (lang dune 2.8)
> (wrapped_executables false)
> EOF
$ dune exec ./exe/foo.exe
File "exe/foo.ml", line 1, characters 0-11:
1 | Foo.Bar.run ();;
^^^^^^^^^^^
Error: Unbound module Foo
[1]
$ cat >dune-project <<EOF
> (lang dune 2.8)
> (wrapped_executables true)
> EOF
$ dune exec ./exe/foo.exe
Hello World

View file

@ -0,0 +1,7 @@
(library
(name lib)
(modules :standard \ test))
(executable
(name test)
(libraries lib))

View file

@ -0,0 +1 @@
let run () = print_endline "foo bar"

View file

@ -0,0 +1,21 @@
$ dune exec ./test.exe --debug-dep
File "dune", line 1, characters 0-0:
Error: Module "Lib" is used in several stanzas:
- dune:1
- dune:5
To fix this error, you must specify an explicit "modules" field in every
library, executable, and executables stanzas in this dune file. Note that
each module cannot appear in more than one "modules" field - it must belong
to a single library or executable.
[1]
$ dune build src/a.cma --debug-dep
File "src/dune", line 1, characters 0-0:
Error: Module "X" is used in several stanzas:
- src/dune:1
- src/dune:2
To fix this error, you must specify an explicit "modules" field in every
library, executable, and executables stanzas in this dune file. Note that
each module cannot appear in more than one "modules" field - it must belong
to a single library or executable.
[1]

View file

@ -0,0 +1,2 @@
(library (name a))
(library (name b))