There is a way to fine tune include path for ocamlbuild BUT there is no way I am aware of to do that when library bar will build depends on library foo.
Do you have a working example how to do that with ocamlbuild ?
I see what you mean. You rely on the fact that you can create .mlpack outside of the directory... This will create the target file outside of the directory and allows to hide implementation.
Right now, a little voice tells me: "what if the sources are in . (toplevel directory) for foo". Answer is probably that it will fail again...
So we are left with only one solution:
Create a specific directory for pack that will contains all .mlpack (e.g pack/ or builddef/ or ???)
Actually that may be a good idea, but I am not yet 100% sure. BTW, this will also allow to generate .mllib with a better separation of internal/public modules.
gildor478
commented
4 years ago
This bug has been migrated from artifact #1383 on forge.ocamlcore.org. It was assigned to user102.
user112 posted on 2014-03-31 13:34:35:
oasis does not seem to be able to build multiple libraries from a single _oasis file while keeping internal modules hidden.
For example, if I have two libraries each with a module A which is unique to the respective modules:
Library foo Path: foo/ Pack: true Modules: A ...
Library bar BuildDepends: foo Path: bar/ Pack: true Modules: A ...
then compilation will fail because foo/a.cmi and bar/a.cmi do not match. I would expect foo/a.cmi to be hidden during the compilation of Bar.
user102 replied on 2014-03-31 16:06:25:
There is a way to fine tune include path for ocamlbuild BUT there is no way I am aware of to do that when library bar will build depends on library foo.
Do you have a working example how to do that with ocamlbuild ?
user112 replied on 2014-04-01 16:32:58:
I've attached a simple example. "ocamlbuild bar.cma" works in this case.
user102 replied on 2014-04-01 16:57:08:
I see what you mean. You rely on the fact that you can create .mlpack outside of the directory... This will create the target file outside of the directory and allows to hide implementation.
Right now, a little voice tells me: "what if the sources are in . (toplevel directory) for foo". Answer is probably that it will fail again...
So we are left with only one solution: Create a specific directory for pack that will contains all .mlpack (e.g pack/ or builddef/ or ???)
Actually that may be a good idea, but I am not yet 100% sure. BTW, this will also allow to generate .mllib with a better separation of internal/public modules.
user112 replied on 2014-04-01 17:54:51:
I agree that it seems like a good approach. pack/ or _oasis/ for a directory perhaps?
user102 replied on 2014-04-01 21:33:24:
I think we should start with pack/ and see if this can be good as well to isolate .mllib file (after all why not).
What about creating a feature for this new source layout ?
user112 replied on 2014-04-02 13:11:57:
A new feature sounds like a good approach. I'm happy to help test.
user102 replied on 2014-04-02 14:21:40:
Right now, it is not high priority for the next release (which will probably focus on Windows...)
Scheduling for the next one, hopefully.