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
provide an explicit flag -assume-no-mli
for reliable build tools
#7383
Comments
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 |
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. |
@bobzhang What's the situation on this ? I think a PR would be welcome. |
We have this for bucklescript, and turned on by default so that whether you
have mli or not will not affect the build at all, you have to tell the
compiler explicitly using the mli file.
What do other people from the core team think about this?
…On Sat, May 9, 2020 at 11:55 PM Gabriel Radanne ***@***.***> wrote:
@bobzhang <https://github.com/bobzhang> What's the situation on this ? I
think a PR would be welcome.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7383 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFWMK4TMDAEN2R3IEJC24LRQV4GXANCNFSM4M4UFJ3A>
.
--
Regards
-- Hongbo Zhang
|
I think it's backward. Having an explicit .mli interface is the rule, not the exception. |
I am not arguing that whether we should have mli file or not. My point was
that accidentally adding or removing a mli file should not affect the
build, using cmi produced by mli should be explicit instead of relying on
the file system, does this sound good to you?
Xavier Leroy <notifications@github.com>于2020年5月10日 周日下午3:45写道:
I think it's backward. Having an explicit .mli interface is the rule, not
the exception.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7383 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFWMK3THCFH4YQKQ4FFOS3RQZLRTANCNFSM4M4UFJ3A>
.
--
Regards
-- Hongbo Zhang
|
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. |
@xavierleroy sorry I did not explain it clearly.
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. |
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:
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.
The text was updated successfully, but these errors were encountered: