Give Stdlib its own directory#19530
Conversation
f662bb1 to
a8870c5
Compare
a8870c5 to
2f58b04
Compare
example_055 may reveal an actual issue though
2f58b04 to
ec087ab
Compare
ec087ab to
d509a55
Compare
example_055 may reveal an actual issue though
d509a55 to
c015af0
Compare
c015af0 to
9012c59
Compare
Using the previously introduced extra option
This is only the coq-stdlib package in current dir that now only contains the prelude and a few other things. The actual coq-stdlib package in stdlib dir remains untouched.
And add a compat layer in Stdlib.
|
Windows CI is no longer failing on |
|
Yes, that's expected, the windows CI being based on the core-dev opam repo, it will require an update of the coq.opam package there when merging, hence the checkbox in the top message. |
|
OK, then I can proceed with merging? |
|
@coqbot merge now |
|
@Zimmi48: Please take care of the following overlays:
|
Are you sure? In the rocq cli prototype windows is passing even though I added rocq-runtime |
|
The difference is that the coq-stdlib package is no longer in the root directory I think, so the one in core-dev must be right. |
|
I believe this PR has been merged too eagerly. The coq-tools overlay PR was only created within the past 24 hours and is not in a mergable state, despite apparently supposed to be merged in sync with this PR. The overlay breaks the ability of the bug minimizer to minimize across different versions of Coq. I do not understand the difference between Corelib and Stdlib well enough to fix it (and am currently too busy to figure this out). @proux01 @Zimmi48 could one of you fix the coq-tools overlay ASAP or else revert this PR? |
|
@JasonGross , you can regard This PR indeed did a large amount of loosely changes at the same time, so apart from the renaming of |
|
Sorry @JasonGross, I was not aware that the coq-tools overlay was new from Corelib and had not been reviewed yet. |
|
FYI @proux01 the merge of this PR broke the Maybe you could have opened an overlay for Docker-Coq and Docker-Rocq (albeit this situation is very rare), For the time being, I'll try to fix the build and let you know in this thread. |
|
FYI the build failed anew because it still tries to install coq-stdlib to no avail: should this line be removed or changed? https://github.com/coq/coq/blob/476460fb01e3f40edf2f4a63470d0cbbd1d89f7a/coq.opam#L28 |
|
@erikmd indeed the core-dev opam packages were broken, should be fixed now: rocq-prover/opam#3244 |
|
OK ! Did you check that the package is fixed also in core-dev / extra-dev ? Cannot check right now as I'm away from keyboard right now - texting from my cell phone |
This is a first step to implements part of CEP#83 that reached a common agreement during the dedicated Coq call discussions (tl;dr: give stdlib its own repository, clarify its internal dependencies and ensure they are kept with a CI check, "coq" metapackage keeps depending on "coq-stdlib" and no distribution of packages for induvidual subcomponents) The other parts are PR_to_open and rocq-prover/stdlib#2
theories/between Coq repo (here) and stdlib directory, almost everything (185 kloc) in stdlib but (16 kloc)prelude (6 kloc): everything in
Prelude.v, in practiceInit/*SetoidandProgramand dependencies (4 kloc)BinNums(1 kloc),List(145 loc), needed for primitive typesprimitive types and their axioms (1262 loc) since they specify things in the kernel:
Floats(726 loc),Int63(357 loc),Strings(112 loc) andArray(67 loc)ssreflect (4 kloc)
(after last rebase, just before merging) check again that all .v files from
theories/ends up in exactly one of the two directoriestest-suite/ends up in exactly one of the two directoriescoq-stdlibOPAM package in Coq repo (with now only prelude) torocq-init,coq-stdlibbeing now the StdlibOverlays (to be merged before the current PR)
Overlays (to be merged in sync with the current PR)
Free overlays (can be merged or not before or after merging the current PR)