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

cmo -> cma rule brings too much dependencies in #5208

Closed
vicuna opened this issue Jan 20, 2011 · 6 comments
Closed

cmo -> cma rule brings too much dependencies in #5208

vicuna opened this issue Jan 20, 2011 · 6 comments

Comments

@vicuna
Copy link

vicuna commented Jan 20, 2011

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 :

cd /tmp
echo "let f x = x + 1" > a.ml
echo "let f x = A.f x" > b.ml
ocamlbuild -classic-display b.cma
/usr/local/bin/ocamldep.opt -modules b.ml > b.ml.depends
/usr/local/bin/ocamldep.opt -modules a.ml > a.ml.depends
/usr/local/bin/ocamlc.opt -c -o a.cmo a.ml
/usr/local/bin/ocamlc.opt -c -o b.cmo b.ml
/usr/local/bin/ocamlc.opt -a a.cmo b.cmo -o b.cma

However I expected only b.cmo in that cma for the following reason :

ocamlbuild -classic-display b.cmxs
/usr/local/bin/ocamlopt.opt -shared b.cmx -o b.cmxs

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

@vicuna
Copy link
Author

vicuna commented Jan 20, 2011

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

@vicuna
Copy link
Author

vicuna commented Jan 20, 2011

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.

@vicuna
Copy link
Author

vicuna commented Sep 19, 2012

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.

@vicuna
Copy link
Author

vicuna commented Aug 13, 2013

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.)

@vicuna
Copy link
Author

vicuna commented Feb 20, 2017

Comment author: @xavierleroy

Un-assigning from xclerc

@vicuna
Copy link
Author

vicuna commented Feb 20, 2017

Comment author: @dbuenzli

I think this should be closed.

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