Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005628OCamlOCaml internal build/install (Makefiles, configure)public2012-05-31 14:272012-07-07 17:37
Reportergerd 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusconfirmedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0005628: ocaml-4 and findlib issues
DescriptionThe 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 InformationPossible 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.
TagsNo tags attached.
Attached Files

- Relationships

-  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


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker