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
ocamlc/ocamlopt better support for precise builds #7080
Comments
Comment author: @alainfrisch I think this is a good direction, but it will quickly illustrate that ocamldep does not return an over approximation of actual dependencies, so your build system will have trouble passing all the required .cmi files (or it needs to pass the full transitive closure of dependencies, but this can get big). This is documented in: |
Comment author: @dbuenzli @Frisch I was more thinking this for expressing dependencies over the files of packages whose usage is declared not discovered. Note that an alternative/companion idea would be to record all the files that were actually accessed and used in the generated cmt[i] files. Though one might argue that the digests already somehow record this, except in cmo files if I'm not mistaken. (sorry Xavier about the dupe) |
Comment author: @lpw25 The cmo file should contain an accurate account of what was accessed in the digests (that's why I added support for listing imports without their digest). As for the proposal: I hope to add something similar as part of my namespacing proposal. Although since the number of files passed via Adding something before my proposal is ready might be a good idea, but I would ask that it try to be forwards compatible with what I have in mind. |
Comment author: @dbuenzli Silly me there's no notion of imported implementation in cmo files. |
Comment author: @shindere For .cmi files I think I can understand what you are looking for, but I don't understand why you mention .cmx files and not .cmo files. |
Comment author: @alainfrisch "ocamlc -c foo.ml" will never load bar.cmo implicitly. "ocamlopt -c foo.ml" might load "bar.cmx" and "bar.cmi". I think the idea here is to be fully explicit. |
Comment author: @dbuenzli Yes that's what Alain says. The notion of include requires build system to record negative information (there was no Also when we actually do have the precise path information it is silly to unprecise it to a |
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. |
I still think it's a good idea if we can pass the toolchain the objects we want it to consider to do its job explicitely. |
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. |
This is a good general suggestion, let's try to move #9056 forward. |
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. |
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: 7080
Reporter: @dbuenzli
Status: acknowledged (set by @damiendoligez on 2017-02-28T15:59:58Z)
Resolution: open
Priority: high
Severity: feature
Version: 4.02.3
Category: compiler driver
Has duplicate: #7475
Related to: #5624
Monitored by: @nojb @shindere @diml @hcarty
Bug description
It would be nice to be able to specify cmi and cmx files directly on the command line when compiling with -c rather than using -I includes which can be too coarse and lead to subtle (non)rebuild errors in incremental build systems. This should go in pair with an option not to include the current directory in the search path.
Thanks.
The text was updated successfully, but these errors were encountered: