-
Notifications
You must be signed in to change notification settings - Fork 470
Virtual libraries #921
Description
Virtual libraries represent part of library variant proposal. They are much simpler to implement than the full proposal, but are still compatible with the full proposal and represent the most useful part of it, so we should start with them.
User facing features
The user may write (virtual_modules a b c) in a library stanza for a library named foo. This means that modules a, b and c must have a .mli but no .ml and will be implemented by another library. If a library has at least one virtual module we call it a virtual library.
Another library may have (implement foo) in its stanza. This library must provide .ml files for a, b and c but no .mli files. Additionally it must not have .ml or .mli files for any non-virtual modules of foo. Such a library is called an implementation of foo. An implementation can have a public_name but must not have a name field, since it must be the same as the one of the library it implements.
For every virtual library an executable depends on, it must depend on exactly one implementation.
One open question is how to refer to implementations when they don't have a public_name. One possibility is to allow an implmenentation_name field in implementations or a local_names field in all libraries. The latter seems better.
Implementation
virtual_modules can be implemented the same way as modules_without_implementations. Additionally for a virtual library we must not produce any archive file (.cma, .a, ...). The list of virtual modules must be kept around in Lib.t and in the generated META file.
When compiling an implementation, we should copy all the artifacts of the virtual library over and do the rest as usual.
When computing the transitive closure for an executable, we must proceed as follow:
- compute the transitive closure of libraries (as before)
- check that for every virtual libraries in the list we have exactly one corresponding implementation
- recompute the transitive closure, but this time implicitely replace dependency on a virtual library by a dependency on the corresponding implementation