-
Notifications
You must be signed in to change notification settings - Fork 412
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
coqc: ondemand: no such file or directory #4142
Comments
This issue is also happening in Coq bench. For example, see here: https://coq-bench.github.io/clean/Linux-x86_64-4.07.1-2.0.6/released/8.9.1/tactician-dummy/1.0~beta1.html. It appears that this bug was introduced in #3210, in particular here: dune/src/dune_rules/coq_rules.ml Line 162 in 0453da3
Presumably, some kind of special case for older versions of Coq needs to be introduced? |
It seems this commit broke old versions of Coq: 0337d3e |
I assume this was intentional and @ejgallego does not intend to support old versions of coq. |
Well I mean, both the retro-compatibility and the user experience are a bit terrible. I just upgraded dune and my stuff stopped compiling. Note that even using a dune-project that specifies an older version of dune/the coq support doesn't help, the error is still there. |
I didn't do this on purpose, I only test in fact with 8.10 , and didn't recall this option was introduced so recently. So this is a bug. Determining the version of Coq is unfortunately quite tricky, but if someone manages to write something that would work on the composed build I'd be happy to add it. For now I think indeed the best choice is document that coq-lang >= 0.3 is not compatible with Coq < 8.10 , document it, and actually don't add this flag unless the coq version is bumped. WDYT @Armael ? Is dropping support for Coq < 8.10 in coq-lang >= 0.3 a huge problem? Note that we may be able to have to improve on this for example in Coq 8.14 if Coq moves to the split compilation scheme [which would mean that coq-lang >= 0.4 would support back Coq 8.9] |
Having things work again with coq-lang < 0.3 definitely sounds like an improvement; I'm ok with coq-lang 0.3 requiring a more recent version of Coq if that's documented. I was initially wondering if that could be a problem in a fresh setup (where dune automatically generates a dune-project with the most recent dune version), but since the coq-lang directive has to be inserted manually then there should be no problem. |
Coq lang is actually automatically inserted by dune-project auto-generation [if dune sees some coq.theory around] , however that feature is deprecated [due to it being too surprising] so as long as it is properly documented IMHO not a big deal. Will prepare a fix ASAP, pity 2.8.2 just got released so this will have to wait until 2.8.3 :/ |
The best would be of course to be able to expose to dune the proper Coq version, otherwise the workaround is still not very usable as if you use Dropping the explicit option is pretty inconvenient but could be another possibility, tho it would incur in a large cost for nothing when people set Coq to produce native objects by default [which is a large mistake by itself] |
Fixes ocaml#4142. Changes introduced in ocaml#3210 meant that Dune became incompatible with Coq < 8.10 ; this was not intentional and it turns out we had Coq Dune users in Coq 8.9 / 8.8. Indeed `(using coq 0.3)` does require Coq >= 8.10, but when `(using coq 0.2)` is set, we should remain compatible with Coq 8.7-8.9. Signed-off-by: Emilio Jesus Gallego Arias <[email protected]>
Fixes ocaml#4142. Changes introduced in ocaml#3210 meant that Dune became incompatible with Coq < 8.10 ; this was not intentional and it turns out we had Coq Dune users in Coq 8.9 / 8.8. Indeed `(using coq 0.3)` does require Coq >= 8.10, but when `(using coq 0.2)` is set, we should remain compatible with Coq 8.7-8.9. Signed-off-by: Emilio Jesus Gallego Arias <[email protected]>
Fix incoming, sorry I missed Dune 2.8.2 , I'm unsure if there will be a 2.8.3 :S |
Fixes ocaml#4142. Changes introduced in ocaml#3210 meant that Dune became incompatible with Coq < 8.10 ; this was not intentional and it turns out we had Coq Dune users in Coq 8.9 / 8.8. Indeed `(using coq 0.3)` does require Coq >= 8.10, but when `(using coq 0.2)` is set, we should remain compatible with Coq 8.7-8.9. Signed-off-by: Emilio Jesus Gallego Arias <[email protected]>
If the bugfix is important for users, we should release a 2.8.3. |
The set of users is quite small [I thought it was empty] , so not entirely sure about doing the 2.8.3 effort if that's the only fix we'd add there, as opposed to a 2.9.0 later on. |
Fixes #4142. Changes introduced in #3210 meant that Dune became incompatible with Coq < 8.10 ; this was not intentional and it turns out we had Coq Dune users in Coq 8.9 / 8.8. Indeed `(using coq 0.3)` does require Coq >= 8.10, but when `(using coq 0.2)` is set, we should remain compatible with Coq 8.7-8.9. Signed-off-by: Emilio Jesus Gallego Arias <[email protected]>
…ne-action-plugin, dune-private-libs and dune-glob (2.8.3) CHANGES: - Make `patdiff` show refined diffs (ocaml/dune#4257, fixes ocaml/dune#4254, @hakuch) - Fixed a bug that could result in needless recompilation under Windows due to case differences in the result of `Sys.getcwd` (observed under `emacs`). (ocaml/dune#3966, @nojb). - Restore compatibility with Coq < 8.10 for coq-lang < 0.3 , document that `(using coq 0.3)` does require Coq 8.10 at least (ocaml/dune#4224, fixes ocaml/dune#4142, @ejgallego) - Add a META rule for 'compiler-libs.native-toplevel' (ocaml/dune#4175, @AltGr) - No longer call `chmod` on symbolic links (fixes ocaml/dune#4195, @dannywillems) - Dune no longer automatically create or edit `dune-project` files (ocaml/dune#4239, fixes ocaml/dune#4108, @jeremiedimino) - Have `dune` communicate the location of the standard library directory to `merlin` (ocaml/dune#4211, fixes ocaml/dune#4188, @nojb) - Workaround incorrect exception raised by Unix.utimes (OCaml PR#8857) in Path.touch on Windows (ocaml/dune#4223, @dra27) - `dune ocaml-merlin` is now able to provide configuration for source files in the `_build` directory. (ocaml/dune#4274, @voodoos) - Automatically delete left-over Merlin files when rebuilding for the first time a project previously built with Dune `<= 2.7`. (ocaml/dune#4261, @voodoos, @aalekseyev) - Fix `ppx.exe` being compiled for the wrong target when cross-compiling (ocaml/dune#3751, fixes ocaml/dune#3698, @toots) - `dune top` correctly escapes the generated toplevel directives, and make it easier for `dune top` to locate C stubs associated to concerned libraries. (ocaml/dune#4242, fixes ocaml/dune#4231, @nojb) - Do not pass include directories containing native objects when compiling bytecode (ocaml/dune#4200, @nojb)
With Coq 8.9.1, after upgrading to dune 2.8.1, compiling coq files does not seem to work anymore (due to unsupported command-line arguments it seems).
Expected Behavior
It works.
Actual Behavior
It does not work.
Reproduction
dune
file:with an empty file
t.v
on the side.Specifications
dune
: 2.8.1ocaml
(output ofocamlc --version
): 4.08.1The text was updated successfully, but these errors were encountered: