You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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.
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.The text was updated successfully, but these errors were encountered: