Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ocamldep generates cmx -> cmx dependencies #4389

Closed
vicuna opened this issue Sep 13, 2007 · 1 comment
Closed

ocamldep generates cmx -> cmx dependencies #4389

vicuna opened this issue Sep 13, 2007 · 1 comment

Comments

@vicuna
Copy link

vicuna commented Sep 13, 2007

Original bug ID: 4389
Reporter: pascal_cuoq
Status: closed (set by @xavierleroy on 2007-11-06T15:53:39Z)
Resolution: won't fix
Priority: normal
Severity: feature
Version: 3.10.0
Category: ~DO NOT USE (was: OCaml general)

Bug description

ocamldep generates dependencies as if native separate compilation did not exist.
That is, with the files :
a.ml:
let x = 1 ;;
a.mli:
val x : int
b.ml:
print_int A.x

The command "ocamldep a.ml a.mli b.ml" generates the dependency:
b.cmx: a.cmx

The dependencies for b.cmo reflect the expected behaviour of
actual separate compilation:
b.cmo: a.cmi

If "ocamlopt" can always handle the link of a.cmx and b.cmx even if a.cmx was built
after b.cmx, this report is a feature request for a "-separate-native-compilation"
option to "ocamldep", that would generate "b.cmx : a.cmi" only in this case.

If "ocamlopt" can not always handle the link of a.cmx and b.cmx if a.cmx was built after
b.cmx (with a.cmi unchanged), this report is a feature request for making this possible,
and then adding the "-separate-native-compilation" option to ocamldep.

Rationale :

Native compilation is faster than bytecode for the case "make big_project regression_tests",
but separate native compilation would be even faster, because a lot of time
is spent in "make big_project" even for small changes.

@vicuna
Copy link
Author

vicuna commented Nov 6, 2007

Comment author: @xavierleroy

If "ocamlopt" can always handle the link of a.cmx and b.cmx even
if a.cmx was built after b.cmx,

Unfortunately, no. This would break cross-module optimizations -- that's the main reason why, with ocamlopt, the implementation of a module A depends on the implementations (not just the interfaces) of A's imported modules.

What you suggest would also require an ocamlopt flag to turn off cross-module optimizations, and perhaps additional link-time checks to validate mixtures of .cmx files compiled with and without cross-module optimizations. I'm not keen to implement this, as I don't see many scenarios where it would be useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant