Skip to content
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

Closed
vicuna opened this issue May 31, 2012 · 11 comments
Closed

ocaml-4 and findlib issues #5628

vicuna opened this issue May 31, 2012 · 11 comments

Comments

@vicuna
Copy link

vicuna commented May 31, 2012

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:

  • 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.

@vicuna
Copy link
Author

vicuna commented Jun 1, 2012

Comment author: @alainfrisch

Couldn't findlib install script copy the subset of required .cmi files into its own directory?

@vicuna
Copy link
Author

vicuna commented Jun 4, 2012

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").

@vicuna
Copy link
Author

vicuna commented Jun 4, 2012

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.

@vicuna
Copy link
Author

vicuna commented Jun 6, 2012

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.

@vicuna
Copy link
Author

vicuna commented Jun 8, 2012

Comment author: @xavierleroy

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.

@vicuna
Copy link
Author

vicuna commented Jun 8, 2012

Comment author: @alainfrisch

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 #5624)

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).

@vicuna
Copy link
Author

vicuna commented Jul 4, 2012

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.

@vicuna
Copy link
Author

vicuna commented Jul 7, 2012

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.

@github-actions
Copy link

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.

@nojb
Copy link
Contributor

nojb commented Jun 22, 2020

I am reopening this issue as it is quite directly addressed by #9056 which is being reviewed.

@github-actions
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants