Do we want plugins and theories in the same package? I am updating some documentation in dune, and I think it would be good to be clear about this point.
Now that a plugin requires a META.plug_file for findlib to work, does it really make sense to have .v files be built as part of that package?
Before the findlib patch, I see a lot of writing about mixing ml files and v files when writing plugins. I think this is a completely bonkers workflow today, but I am open to be convinced otherwise.
Having dune take care of the Declare ML Module
boilerplate sounds like a good idea to me.
I agree it would be nice to have Dune do Declare ML Module
by default, but I don't think it should be impossible to override (i.e., allow people opt in or out)
Declare ML as a vernac command is pretty much unrelated to the build system though.
coqdep still reads it and talks to dune
The issue is that coqdep reads Declare ML Module "public_name" and then adds a dependency on META.public_name
.
Dune will not build the META file until everything in the package has been built (which apparently sometimes included .v files)
if we can somehow make Declare ML be unrelated to the build system, that'd be great...
but there have been 10+ instances where Declare ML and build systems were a headache for me, just in the last six months
The only reason coq_makefile works is because it makes up a META file and inserts it.
This also means that complicated META files have to be preprepared for coq_makefile
I don't see a problem with plugin and theories in the same package. Regarding dune support for newer Coq versions, we need some changes in Coq as the compatiblity layer is broken, and there is a large discrepancy of the meaning of -I for coqdep and coqc in master.
I think for now the easiest is to fix the compat layer which I figured out in https://github.com/coq/coq/pull/15991 , just needs a bit more testing.
The basic problem is that we were not storing if legacy mode was used in the .vo file, but that's needed in order to have a robust setup, there are many other subtle bugs in current code due to non-determinism and the aforementioned discrepancies.
Writing a plugin today is difficult.
Half the time the example plugins I write don't even work.
At the moment, we are not making the plugin authors life easy.
Dune was making the life very easy before the META PR tho
Using dune I could create overlays over all the plugins simultaneously
Right, but today dune is not making life easy, it is making it harder.
So we need to change something in Coq to make this easier.
how is dune making life harder?
it is the Coq implementation that is broken
Not intentionally.
just we didn't test enough
Right, but we are about to do another release and writing a plugin has never been so finicky with dune.
coq_makefile works today, only because it is using a hack
at the moment, the state of affairs is completely broken
What is it that we need to change in Coq to fix this?
POV of the plugin authors:
I am not saying it is dune's fault. I agree with you that dune is doing the right thing.
But Coq is not doing the right thing and it is annoying plugin authors.
Yes, we need to finish https://github.com/coq/coq/pull/15991 which only needs to restore the old -I setup for the compat setting
And additionally cleanup the code as we discussed the other day in the zoom call, in particular remove the non deterministic behavior
also we need to make coqdep and coqc agree on what -I means
which now they don't
IIUC
For https://github.com/coq/coq/pull/15991 , I have a lot of local changes that makes things almost work
and remove all these hacks
I don't know tho when I'll get cycles for that
Emilio Jesús Gallego Arias said:
I don't know tho when I'll get cycles for that
But the fix is pretty easy conceptually: store in the .vo what loading method was used (legacy or META) and add the -I legacy paths
So that is to say, when in legacy mode, do what was done in legacy mode!
Last updated: Oct 13 2024 at 01:02 UTC