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

ocamlc/ocamlopt better support for precise builds #7080

Closed
vicuna opened this issue Dec 9, 2015 · 14 comments
Closed

ocamlc/ocamlopt better support for precise builds #7080

vicuna opened this issue Dec 9, 2015 · 14 comments

Comments

@vicuna
Copy link

vicuna commented Dec 9, 2015

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.

@vicuna
Copy link
Author

vicuna commented Dec 9, 2015

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:

#5624

@vicuna
Copy link
Author

vicuna commented Feb 7, 2017

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)

@vicuna
Copy link
Author

vicuna commented Feb 7, 2017

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 -I can easily be huge (beyond the number of allowed command-line params on some systems IIRC) it will use a text file listing the desired files (i.e. -I dependencies.txt). It will also give explicitly the mapping between names and files rather than relying on the basename of the cmi file, which helps when the namespace becomes hierarchical (as it does in my proposal).

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.

@vicuna
Copy link
Author

vicuna commented Feb 7, 2017

Comment author: @dbuenzli

@lpw25 maybe there's something I'm missing but doesn't the cmo file contain digests of the interfaces (i.e. cmi file) of the cmo ? However cmos with different digests can implement the same cmi digest no ?

@vicuna
Copy link
Author

vicuna commented Feb 7, 2017

Comment author: @dbuenzli

Silly me there's no notion of imported implementation in cmo files.

@vicuna
Copy link
Author

vicuna commented Feb 24, 2017

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.
Also, could you mention a concrete example where this feature would be helpful?
Finally, do you think the files to use should just be mentionned on the command-line or should they be preceeded by a flag?

@vicuna
Copy link
Author

vicuna commented Feb 24, 2017

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.

@vicuna
Copy link
Author

vicuna commented Feb 24, 2017

Comment author: @dbuenzli

Yes that's what Alain says.

The notion of include requires build system to record negative information (there was no bar.cmi in the -I inc directory.

Also when we actually do have the precise path information it is silly to unprecise it to a -I option so that the toolchain redoes the lookup itself.

@github-actions
Copy link

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 11, 2020
@dbuenzli
Copy link
Contributor

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.

@ghost ghost removed the Stale label May 12, 2020
@github-actions
Copy link

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 14, 2021
@gasche gasche removed the Stale label May 14, 2021
@gasche
Copy link
Member

gasche commented May 14, 2021

This is a good general suggestion, let's try to move #9056 forward.

@github-actions
Copy link

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
Copy link

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 19, 2023
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

4 participants