0005628: ocaml-4 and findlib issues

Notes
(0007489) frisch (developer) 2012-06-01 05:24	Couldn't findlib install script copy the subset of required .cmi files into its own directory?

(0007513) gerd (reporter) 2012-06-04 15:26	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").

(0007514) frisch (developer) 2012-06-04 15:36	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.

(0007518) gasche (developer) 2012-06-06 10:19	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.

(0007523) xleroy (administrator) 2012-06-08 13:25	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.

(0007528) frisch (developer) 2012-06-08 15:39	> 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).

(0007631) gasche (developer) 2012-07-04 17:39	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.

(0007650) gasche (developer) 2012-07-07 13:46	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.

Issue History
Date Modified	Username	Field	Change
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

Relationships