You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 1726 Reporter: administrator Status: closed Resolution: won't fix Priority: normal Severity: feature Category: ~DO NOT USE (was: OCaml general)
Bug description
Dear Camlists,
I've tripped over a bug in ocamldep. In the example below, note that
the I.t mentioned in file a.ml comes from the signature B.S. Ocamldep
mistakenly introduces a dependency on i.cmo. This problem is causing
us a small inconvenience in our build process.
Norman
: nr@flatcoat 2655 ; cat a.ml
module type S = sig
include B.S
val x : I.t
end
: nr@flatcoat 2656 ; cat b.ml
module type S = sig
module I : sig
type t = int
end
end
: nr@flatcoat 2657 ; cat i.ml
type y = string
: nr@flatcoat 2658 ; ocamldep *.ml
a.cmo: b.cmo i.cmo
a.cmx: b.cmx i.cmx
: nr@flatcoat 2659 ; ocaml < /dev/null
Objective Caml version 3.06
: nr@flatcoat 2663 ; uname -a
Linux flatcoat 2.2.20 #8 Sun Oct 6 16:33:50 EDT 2002 i686 unknown
The text was updated successfully, but these errors were encountered:
I've tripped over a bug in ocamldep. In the example below, note that
the I.t mentioned in file a.ml comes from the signature B.S. Ocamldep
mistakenly introduces a dependency on i.cmo. This problem is causing
us a small inconvenience in our build process.
Yes, it's a known problem with "include" in Caml or "open" in SML.
I think Matthias Blume (or perhaps Andrew Appel) wrote eloquently
about it. Basically, to circumvent it, ocamldep would need to perform
most of the type-checking of the module language (to determine the
signature of the "included" path), and this would be a mess, both
conceptually and implementation-wise.
The workaround that I use is to make sure that module components of
included things have different names than existing compilation units,
e.g. in your example
: nr@flatcoat 2656 ; cat b.ml
module type S = sig
module I : sig
type t = int
end
end
: nr@flatcoat 2657 ; cat i.ml
type y = string
either rename the I component of B.S, or rename the i.ml file.
Not pretty, I know.
Original bug ID: 1726
Reporter: administrator
Status: closed
Resolution: won't fix
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)
Bug description
Dear Camlists,
I've tripped over a bug in ocamldep. In the example below, note that
the I.t mentioned in file a.ml comes from the signature B.S. Ocamldep
mistakenly introduces a dependency on i.cmo. This problem is causing
us a small inconvenience in our build process.
Norman
: nr@flatcoat 2655 ; cat a.ml
module type S = sig
include B.S
val x : I.t
end
: nr@flatcoat 2656 ; cat b.ml
module type S = sig
module I : sig
type t = int
end
end
: nr@flatcoat 2657 ; cat i.ml
type y = string
: nr@flatcoat 2658 ; ocamldep *.ml
a.cmo: b.cmo i.cmo
a.cmx: b.cmx i.cmx
: nr@flatcoat 2659 ; ocaml < /dev/null
Objective Caml version 3.06
: nr@flatcoat 2663 ; uname -a
Linux flatcoat 2.2.20 #8 Sun Oct 6 16:33:50 EDT 2002 i686 unknown
The text was updated successfully, but these errors were encountered: