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
cmo -> cma rule brings too much dependencies in #5208
Comments
Comment author: ertai If you want to manually choose the list of modules which goes into the library then I suggest you the use of .mllib files. The rule from .cmo to .cma takes the transitive closure of its dependencies by default. HTH |
Comment author: @dbuenzli I understand that but I think that's not what you want in practice and it's inconsistant with the rule for .cmx -> .cmxs. |
Comment author: @damiendoligez But it's consistent for the rule for .cmx -> .cmxa. The problem is that .cma is the pendant of both .cmxa and .cmxs and ocamlbuild cannot know whether you are going to dynlink that .cma or link it normally. |
Comment author: @gasche We could consider adding a .shared.cma target that would use the same semantics as .cmxs. (For symmetry it would make sense to name it .cms, but the OCaml compiler will not accept archive files with that extension.) |
Comment author: @xavierleroy Un-assigning from xclerc |
Comment author: @dbuenzli I think this should be closed. |
Original bug ID: 5208
Reporter: @dbuenzli
Status: resolved (set by @damiendoligez on 2017-02-27T13:05:22Z)
Resolution: not a bug
Priority: normal
Severity: minor
Version: 3.12.0
Target version: later
Category: -for ocamlbuild use https://github.com/ocaml/ocamlbuild/issues
Monitored by: mehdi @ygrek @hcarty @dbuenzli
Bug description
When ocamlbuild builds a cma from a cmo it brings too much deps in the cma. For example :
However I expected only b.cmo in that cma for the following reason :
Since cma are the pendant of cmxs for dynamically loaded plugins I expect them to build the same way w.r.t. dependencies. And for plugins you don't want automatically these dependencies since it's likely to be the plugin api itself which will be in the program loading the plugin.
Best,
Daniel
The text was updated successfully, but these errors were encountered: