Closed agarwal closed 9 years ago
Do you intend Oloop_core2
to be used externally?
Do you intend Oloop_core2 to be used externally?
No. It's definitely for internal use only.
Thanks, so you just have to expose the relevant modules. I wasn't sure if there's another solution.
On Fri, 8 May 2015 06:38:00 -0700, Ashish Agarwal wrote:
Thanks, so you just have to expose the relevant modules. I wasn't sure if there's another solution.
Not sure what you mean. What kind of "other solution" do you have in mind?
The API is meant to require that all sub-modules be accessed as Oloop.Foo
rather than Oloop_foo
, so I thought in theory Oloop_foo
shouldn't have to be exposed.
Probably I don't understand what InternalModules does? The oasis documentation says these modules are "not exported", but how is that accomplished?
On Fri, 8 May 2015 08:18:51 -0700, Ashish Agarwal wrote:
The API is meant to require that all sub-modules be accessed as Oloop.Foo rather than Oloop_foo, so I thought in theory Oloop_foo shouldn't have to be exposed.
Probably I don't understand what InternalModules does? The oasis documentation says these modules are "not exported", but how is that accomplished?
I do not remember for sure but I think this is as simple as the .cmi not being distributed.
The _oasis file lists all but the main Oloop module as InternalModules. This is causing some typing problems, which I resolved temporarily by exposing all modules in c465761bec33ab5d5bf79b712001643afa4a78bf.
To reproduce the problem, path pin the repo and git checkout 95fa79aac8f01733a663c143b0d0761f81d8b509, the commit before c465761bec33ab5d5bf79b712001643afa4a78bf. Then try the following two cases:
cd to your working directory and launch utop from there, which will cause the checked-in .ocamlinit file to be used:
Now,
opam install oloop
and try the same thing with the installed version of oloop: