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

Two small error text glitches involving -pack #3028

Closed
vicuna opened this issue Aug 1, 2004 · 3 comments
Closed

Two small error text glitches involving -pack #3028

vicuna opened this issue Aug 1, 2004 · 3 comments

Comments

@vicuna
Copy link

vicuna commented Aug 1, 2004

Original bug ID: 3028
Reporter: administrator
Status: closed (set by @xavierleroy on 2013-08-31T10:46:17Z)
Resolution: won't fix
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)

Bug description

Hi! I'm playing around with making a new build tool, and I just
noticed an inconsistency working with the -pack option. When you
compile a .ml file that has a .mli but not yet a .cmi, you get the
following message:

$ ocamlc -c test1.ml
File "test1.ml", line 1, characters -1--1:
Could not find the .cmi file for interface test1.mli.

When you try to pack a new .cmo or .cmx with a .mli but not yet a
.cmi, you get the following message:

I/O error: test2.cmi: No such file or directory

It all comes down to the same thing, really, but it might be worth
making the error from -pack consistent with at least line two of the
-c output.

The other minor reporting problem is if you combing -pack with -i and
a .ml file. In this circumstance, you get the confusing output:

$ ocamlc -i -pack -o test2.cmo test1.ml
val a : int
Please specify the name of the output file, using option -o

It would be really really nice if this combination instead produced:

module Test1 : sig
val a : int
end

(I'm currently thinking about producing intermediate .mli files for
both ocamlc -c and ocamlc -pack actions in order to simplify things a
bit.) But barring that, reporting that -pack and -i conflict might be
a good idea. (It does work if you give it .cmo files, but only
because -i does nothing when given .cmo files.)

Oh--and as for why I think I want to produce .mli files automatically
for -pack targets: they're needed to use ocamldep to produce any
dependency information at all for such targets, since ocamldep does
not report on modules it can't find a source for in its -I search
path. It still might not be quite satisfactory, I have to think about
it a bit more: but I really don't want to have to either re-implement
ocamldep internally or use a camlp4 hack for this. We'll see.

Here are the test files to reproduce:

-- test1.ml
let a = 1

-- test1.mli
val a : int

-- test2.ml
module Test1 : sig
val a : int
end

$ ocamlc -c test1.ml
File "test1.ml", line 1, characters -1--1:
Could not find the .cmi file for interface test1.mli.
$ ocamlc -c test1.mli
$ ocamlc -c test1.ml
$ ocamlc -pack -o test2.cmo test1.cmo
I/O error: test2.cmi: No such file or directory

@vicuna
Copy link
Author

vicuna commented Jan 12, 2005

Comment author: administrator

Thanks for your bug report,

When you try to pack a new .cmo or .cmx with a .mli but not yet a
.cmi, you get the following message:

I/O error: test2.cmi: No such file or directory

I have fixed this in the CVS version.

The other minor reporting problem is if you combing -pack with -i and
a .ml file. In this circumstance, you get the confusing output:

[...]

It would be really really nice if this combination instead produced:

module Test1 : sig
val a : int
end

I will file this as a feature wish, as it's not so obvious to implement.

-- Damien

@vicuna
Copy link
Author

vicuna commented Jan 12, 2005

Comment author: administrator

Error message : done 2005-01-12 DD
Feature wish: ocamlc -i -pack

@vicuna
Copy link
Author

vicuna commented Jan 30, 2012

Comment author: @damiendoligez

As of 3.12.0, options -i and -pack are incompatible and using both will trigger an error.
I don't think it is possible to implement -i with -pack because -pack accepts .cmo files and the types cannot be recovered from these.

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

1 participant