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

toplevels built with ocamlmktop should automatically get -I dirs added to #directory list #4672

Closed
vicuna opened this issue Dec 16, 2008 · 3 comments

Comments

@vicuna
Copy link

vicuna commented Dec 16, 2008

Original bug ID: 4672
Reporter: warren
Status: acknowledged (set by @damiendoligez on 2009-04-27T14:54:20Z)
Resolution: open
Priority: normal
Severity: feature
Version: 3.10.2
Category: tools (ocaml{lex,yacc,dep,debug,...})
Monitored by: @glondu bacam

Bug description

When ocamlmktop is used to create a toplevel, the -I <dir> argument can be used to supply directories to the search path for .cmi files. However, when the toplevel is run, these directories must be supplied once again. It would be nice if the toplevel that is built would remember these directories.

In practice, I've found new users to be confused by the current behavior. The purpose of creating a toplevel is to create a stand-alone interpreter with all the needed modules pre-linked. However, without supplying the -I directories again (or by supplying them via #directory directives), these modules can't be opened even though their code is included in the toplevel. An "Unbound module" error will result.

As an alternative, perhaps the contents of the .cmi files needed by any linked-in modules could be included in the toplevel automatically. This would avoid the need to search any directories to find them when the toplevel is run. This would make the toplevel more self-contained.

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

@github-actions github-actions bot added the Stale label May 18, 2020
@dbuenzli
Copy link
Contributor

Just to make things clear the reporter doesn't expect this sequence to fail:

> ocamlmktop $(opam var lib)/cmdliner/cmdliner.cma -I $(opam var lib)/cmdliner/ -o a.out 
> ./a.out -noinit
        OCaml version 4.09.0

# open Cmdliner;;
Error: Unbound module Cmdliner

After a bit of head scratching I think maybe this should be labelled as a bug report. The doc string of ocamlmktop in the manpage regarding -I is a bit schizophrenic:

-I directory
  Add the given directory to the list of directories  searched  for  compiled  interface  files
  (.cmo and .cma).

In fact ocamlmktop is essentially a simple link invocation of ocamlc with the right libraries in the right order and these -I are just added to that invocation, not in the resulting toplevel in any way.

It seems the latter would be more useful but it's also a bit more annoying to implement -- you'd need to generate a bit of .ml init code compile and link that in aswell.

@github-actions github-actions bot removed the Stale label Jun 26, 2020
@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