|Anonymous | Login | Signup for a new account||2017-02-24 05:09 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005628||OCaml||configure and build/install||public||2012-05-31 14:27||2012-07-07 17:37|
|Target Version||Fixed in Version|
|Summary||0005628: ocaml-4 and findlib issues|
|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:|
- Leave Topdirs and Toploop in the main stdlib
- Have a separate directory toploop-libs
- Add a possibility to remove entries from the search path (could be a normal function in Toploop)
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.
|Tags||No tags attached.|
|Couldn't findlib install script copy the subset of required .cmi files into its own directory?|
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").
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.
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.
Off the top of my head:
> 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"
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.
> 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.
I like this proposal, and I suggest to adapt the -I command-line
option accordingly (or just allow to pass .cmi files directly).
This would have an extra advantage: one could instruct the build
system (e.g. omake) to pass the explicit list of all .cmi files which
it considers as being dependencies (i.e. basically do the lookup for
.cmi files outside the compiler). (see 0005624)
And what about allowing to pass a reference to a text file with one
.cmi file per line? So a library could export various "set of
interfaces" to be used by different kinds of "client" code (to give
visibility to more or fewer internal modules).
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.
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.
|2012-05-31 14:27||gerd||New Issue|
|2012-06-01 05:24||frisch||Note Added: 0007489|
|2012-06-01 05:24||frisch||Assigned To||=> frisch|
|2012-06-01 05:24||frisch||Status||new => acknowledged|
|2012-06-01 05:24||frisch||Assigned To||frisch =>|
|2012-06-04 15:26||gerd||Note Added: 0007513|
|2012-06-04 15:36||frisch||Note Added: 0007514|
|2012-06-06 10:19||gasche||Note Added: 0007518|
|2012-06-08 13:25||xleroy||Note Added: 0007523|
|2012-06-08 15:39||frisch||Note Added: 0007528|
|2012-07-04 17:18||doligez||Target Version||=> 4.00.0+dev|
|2012-07-04 17:33||gasche||Assigned To||=> gasche|
|2012-07-04 17:33||gasche||Status||acknowledged => assigned|
|2012-07-04 17:39||gasche||Note Added: 0007631|
|2012-07-07 13:46||gasche||Note Added: 0007650|
|2012-07-07 13:46||gasche||Assigned To||gasche =>|
|2012-07-07 13:46||gasche||Status||assigned => confirmed|
|2012-07-07 13:49||gasche||Severity||minor => feature|
|2012-07-07 13:49||gasche||Reproducibility||have not tried => N/A|
|2012-07-07 13:49||gasche||Target Version||4.00.0+dev =>|
|2012-07-07 13:49||gasche||Additional Information Updated||View Revisions|
|2017-02-23 16:38||doligez||Category||OCaml internal build/install (Makefiles, configure) => configure and build/install|
|Copyright © 2000 - 2011 MantisBT Group|