It would be nice if we could add Opam packages in the coq-core-dev repo for coq-core and coq-stdlib. I can make a pull request for this, but I don´t know if there are any strong opinions about using the opam files automatically generated by dune. Would it be a problem to switch from the make-based system to the dune-based system for opam?
I think for coq-core
you can use the opam file, for coq-stdlib I'd use the make call, as we didn't merge the support for the native compute separate compiler yet. You may want to wait until we merge https://github.com/coq/coq/pull/13617 tho.
Ah looks like that will merge soon. I´ll indeed wait.
Given that https://github.com/coq/coq/pull/13617 was merged long ago, I'm trying to prepare a PR to finally have the package split in the opam repo. One issue I'm not sure how to resolve is dealing with the coq-native
package/flag. How do I incorporate this into opam files generated by dune?
You probably just heva to keep the configure call into the coq-core package.
Ah, okay I'll try that. Thanks
I don't think it's yet possible to do the split in the opam repo because the full Dune build does not support native compilation of the standard library yet.
Théo Zimmermann said:
I don't think it's yet possible to do the split in the opam repo because the full Dune build does not support native compilation of the standard library yet.
Ah, okay. I was not aware of that. I just opened this PR: https://github.com/coq/opam-coq-archive/pull/1801
Indeed, the make-based build for the .vo parts does not support using installed Coq to compile, tho, that should be very easy to work around, you just need to tweak the makefiles so COQC
COQDEP
and a couple of other tools are taken from the installed path
@Emilio Jesús Gallego Arias I tried changing CBIN
in Makefile.common
to point to the installed binaries, but this does not work. I also tried changing CONTEXT
and BCONTEXT
, but it makes no difference.
$ make -f Makefile.make coqlib
make --warn-undefined-variable --no-builtin-rules -f Makefile.build coqlib
make[1]: Entering directory '/home/lasse/Documents/Projects/Tactician/tmp-split/coq'
DUNE sources
DUNE /home/lasse/Documents/Projects/Tactician/tmp-split/_opam/bin//coqc
COQCBOOT theories/Init/Notations.v
DUNE _build/default/plugins/ltac/ltac_plugin.cmxs
COQCBOOT theories/Init/Ltac.v
File "./_build_vo/default//lib/coq/theories/Init/Ltac.v", line 11, characters 0-32:
Error: Dynlink error: implementation mismatch on Stdarg
make[1]: *** [Makefile.build:333: _build_vo/default//lib/coq/theories/Init/Ltac.vo] Error 1
make[1]: *** [_build_vo/default//lib/coq/theories/Init/Ltac.vo] Deleting file '_build_vo/default//lib/coq/theories/Init/Ltac.glob'
Mhm, okay that error was due to some old files left lying around. But I tried running the coqlib
target with a completely unmodified version of master
, and that also does not work:
$ make -f Makefile.make coqlib
make --warn-undefined-variable --no-builtin-rules -f Makefile.build coqlib
make[1]: Entering directory '/home/lasse/Documents/Projects/Tactician/tmp-split/coq'
DUNE _build/install/default/bin/coqdep
DUNE sources
COQDEP VFILES
DUNE sources
DUNE _build/install/default/bin/coqc
COQCBOOT theories/Init/Notations.v
Error: Cannot find plugins directory
Looks like the plugins directory ends up in _build
, while the make file expects it to be in _build_vo
Umm, you need to patch things a bit more, in particular when, let's say, building from an installed coq-core package, the makefiles should:
_build should not be involved at all here
actually there is this Draft PR switching the build of the stdlib to coq makefile
maybe that would be a quicker path
to tweak this, I'd advise to define a BUILD_VO_FROM_INSTALLED_COQ make var
and just wrap everything in the bridge file [common] there
so you start with a kind of "minimal" make file for the VO files
then you just need to setup the copy of the files
and the couple of binary paths for COQDEP and COQC
I see, that sounds like quite a few changes will be needed. I was hoping to have this for 8.14, but this sounds like that would probably not be possible. (Let me know if I'm wrong). If we are targetting 8.15, and a lot of changes need to be done, and you'd like me to be involved, it might be a good idea to have a bit more coordination on it (instead of me just hacking away on it randomly).
Last updated: Jun 05 2023 at 09:01 UTC