Using -opaque on an .ml file means that its implementation should not be considered for cross-module inlining. Using -opaque on an .mli file means that no implementation of that interface should be considered for cross-module inlining.

I have a more semantic/indirect definition for what -opaque is, or at least should be: -opaque should guarantee that, if a module that is compiled with -opaque changes its implementation and gets recompiled, then its dependencies do not need to be recompiled as well. For now I think that both definitions coincide, but that is the "no implementation-dependency on opaque modules" that needs to be preserved in the future.

I like the feature, and the code seems fairly simple and very reasonable. In favor.

I have a more semantic/indirect definition for what -opaque is, or at least should be: -opaque should guarantee that, if a module that is compiled with -opaque changes its implementation and gets recompiled, then its dependencies do not need to be recompiled as well.

I would actually go further and define it in terms of being able to choose between different implementations at link-time.

I'll tidy up the code, warning message and changes file this evening.

I wanted to merge this PR right now, but in fact it now conflicts with @alainfrisch 's change on compilation unit deprecation. Could you rebase the patchset against the current trunk? In addition, it would be nice if you could:

• squash the minor fixup commits (it's nice to have separate commits for modified install rules, but the rest is just noise)
• add a very small testsuite exercising both -opaque on ml files (the test could simply modify the source, rebuild and relink as a way to check that a dependency was really seing the compilation unit as opaque), on mli files (same thing, but with -opaque passed earlier in the compilation chain), and the warning.

I've fixed the message, rebased and added tests for both -opaque and the new warning.

Nice PR, thanks!

@lpw25 with more usage experience, there is one aspect of this change that I'm not fully satisfied with: it is the fact that -opaque is only supported by ocamlopt, not ocamlc. This means that people that want to compile a .mli to produce an opaque .cmi have to use ocamlopt -opaque, and cannot use ocamlc -opaque for this purpose. This changes the previously-true property that either compiler can be used to compile interfaces, and I wouldn't be surprised if some makefiles or build systems relied on it.

I think that with your change, we should add -opaque as an option to ocamlc as well. If you agree, would you maybe have the time to do this change in the following days? (I probably don't, but we could consider asking someone else.)

I completely agree, in fact I consider this to be a bug as it was not intentional. However, I'm not sure that I'll have time to look at this in the next few days.

ping