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

Jump to bottom

provide an explicit flag -assume-no-mli for reliable build tools #7383

Closed
vicuna opened this issue Oct 10, 2016 · 9 comments
Closed

provide an explicit flag -assume-no-mli for reliable build tools #7383

vicuna opened this issue Oct 10, 2016 · 9 comments
Labels
compiler-driver feature-wish Stale

Comments

@vicuna
Copy link

vicuna commented Oct 10, 2016

Original bug ID: 7383
Reporter: @bobzhang
Status: acknowledged (set by @damiendoligez on 2017-02-27T15:15:10Z)
Resolution: open
Priority: normal
Severity: feature
Category: compiler driver

Bug description

currently in typemod.ml, there are such lines of code:

    let sourceintf =
      Filename.remove_extension sourcefile ^ !Config.interface_suffix in
    if Sys.file_exists sourceintf then begin

this makes it very hard to build reliable build tool (unless constantly check file system). suppose the file system does not have .mli in the beginning, but later add it, the build system is not aware of it without watching the file system, but it does change the build behavior and will cause some subtle bugs.
@vicuna
Copy link
Author

vicuna commented Feb 27, 2017

Comment author: @damiendoligez

Note: we had a discussion at the latest developer meeting on this topic, and the conclusion was that we also want a flag to force an error when the .mli is absent. I think it was while discussing #682

@github-actions
Copy link

github-actions bot commented May 9, 2020

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 9, 2020
@Drup
Copy link
Contributor

Drup commented May 9, 2020

@bobzhang What's the situation on this ? I think a PR would be welcome.

@bobzhang
Copy link
Member

bobzhang commented May 10, 2020 via email

@xavierleroy
Copy link
Contributor

I think it's backward. Having an explicit .mli interface is the rule, not the exception.

@bobzhang
Copy link
Member

bobzhang commented May 10, 2020 via email

@xavierleroy
Copy link
Contributor

My point was that accidentally adding or removing a mli file should not affect the build

I still don't get it. A .mli file is a source file like any other. "Accidentally" adding or removing a source file does affect the build, most of the time, and for the very good reason that the build system needs to know what are the source files.

@bobzhang
Copy link
Member

@xavierleroy sorry I did not explain it clearly.

ocamlc -I ..  -c foo.ml

By reading this command alone, the behavior is non-deterministic depending on whether there's foo.mli in the search path.
What I hope is some more deterministic behavior:

ocamlc -I .. -c foo.ml # not checking foo.mli at all

ocamlc -I .. -assume-mli -c foo.ml # assume foo.mli is there, otherwise error out

@xavierleroy
Copy link
Contributor

By reading this command alone, the behavior is non-deterministic depending on whether there's foo.mli in the search path.

Not "in the search path": in the same directory.

I'm tired of this discussion. We've been doing that since 1990 or so (Caml Light). You seem to be the first to be surprised. All the build systems handle the two cases (with / without .mli) just fine. Closign this non-issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler-driver feature-wish Stale
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@bobzhang @Drup @xavierleroy @vicuna