Open rgrinberg opened 6 years ago
At some point we talked about making the implementation depend on the virtual library. Doesn't that solve this issue?
At some point we talked about making the implementation depend on the virtual library
Indeed, this change has been done.
Doesn't that solve this issue?
I don't think it solves all the problems however. For example, when a user navigates to the source of virtual library implementation and then tries to switch to an mli file. Also, the missing cmt's and cmti's are bound to break some merlin behavior for vlib implementations.
Have you checked what's broken? I suggest to worry about that once everything else is working.
Currently, it's just the installation of virtual libraries that it broken. Easiest way to fix it would be to stop requiring all these extra artifacts that come from the virtual lib when installing the implementation. I can just fix that by not requiring the extra stuff. I would like #1409 merged however as it moves around some installation related stuff.
There's a couple of problems:
The cmt and cmti files of the modules that belong to the virtual library aren't installed with the implementation.
The sources of the modules that belong to virtual library aren't installed along with the implementation.
The simplest way to fix this would be to simply copy these along from the virtual library to the implementation. However, this becomes a bit more complicated when the virtual library is external.
My main concern is to keep the cmt dependant functionality working (go to definition, etc), so I think copying the sources and cmt's is the way to go for now. But if there's a way to make the tooling work, that would obviously be preferable.