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
ocaml-4 and findlib issues #5628
Comments
Comment author: @alainfrisch Couldn't findlib install script copy the subset of required .cmi files into its own directory? |
Comment author: gerd Alain, yes, this would be a workaround. I don't really like it, though, because having the same interfaces in several directories could lead to confusion. Normally, this is something you try to avoid for administrative reasons (i.e. can you really be sure that the files in compiler-libs and findlib are identical). There is one further idea: allow cherry-picking of interfaces. One simply allows to include full paths to cmi files into the search path, #directory "/path/to/module.cmi" (or just "/path/to/module"). Well, "directory" is probably not a good name for this directive anymore then (rename it to "#search"). |
Comment author: @alainfrisch Gerd: what about symlinks? (with a fallback on copy under Windows) But I agree that a mechanism for controlling precisely which interfaces are available would be nice. In addition to specifying a single .cmi file on the command-line (or with a toplevel directive), one could refer to text files that contain a list of relative paths to such .cmi files. Such a project interacts strongly with various proposals about namespaces which are (more or less) discussed these days. |
Comment author: @gasche The third proposal of gerd, adding the ability to remove entries from the search path, looks like a reasonably clean and future-proof solution to this precise problem (while I certainly agree that in general search-path is problematic and a finer control over compilation environment would be better, this won't be done for 4.00). Is there any reason why this could not or should not be implemented? If it's not a bad idea, maybe we could ask Jérémie, he's knowledgeable about the toplevel and could probably look at this if kindly asked. |
Comment author: @xavierleroy Off the top of my head:
We might be able to overload the #load directive (and the corresponding Toploop function) to do this: if the given filename ends in .cmi, load it into the compiler's cache for compiled interfaces, so that it won't be searched in the file system at the first reference to the corresponding module. A function to remove an entry from the search path is also a sensible solution. |
Comment author: @alainfrisch
I like this proposal, and I suggest to adapt the -I command-line This would have an extra advantage: one could instruct the build And what about allowing to pass a reference to a text file with one |
Comment author: @gasche I would like to implement the simple "remove a dir from search path" before the release. I'll look at the "overloaded #load 'foo.cmi'"; I think both solutions are complementary and may be implemented at the same time, but my guess was that the latter one is a bit more complex to get right (and could therefore wait after the release). Alain, if you want to implement that second feature, please do not hesitate; I'm marking "assigned" to offload some work, not to lock the issue and/or discussion. And you're definitely more knowledgeable than I am about this part of the compiler. |
Comment author: @gasche The change to remove directories from the load path is now upstream; it can be used through either Topdirs.remove_directory or the new #remove_directory directive. Though I think that solves Gerd's immediate concern for "topfind" in 4.00, there may still remains things to be done about the other features discussed here. I'm therefore leaving the bug open, but removing the "must be done before 4.00" tag. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
I am reopening this issue as it is quite directly addressed by #9056 which is being reviewed. |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Original bug ID: 5628
Reporter: gerd
Status: confirmed (set by @gasche on 2012-07-07T11:46:21Z)
Resolution: open
Priority: normal
Severity: feature
Category: configure and build/install
Monitored by: @gasche @diml "Richard Jones"
Bug description
The interfaces for Topdirs and Toploop have been moved to the subdirectory compiler-libs. Findlib uses these modules to add its own directives when loaded via #use "topfind". In order to make it working with ocaml-4 this script needs to be changed so it includes compiler-libs into the search path. Although this works, there is an unintended side effect: All modules of compiler-libs are now visible whenever findlib is activated in the toploop.
This cannot be fixed within findlib, hence I open this bug to discuss the problem.
Additional information
Possible solutions:
Edit (gasche): #remove_directory has been added following the third proposed suggestion. The ability to load cmis by path rather relative to the search path is also considered for inclusion.
The text was updated successfully, but these errors were encountered: