[wish,wip] wacoq build about platform

[ejgallego]

It makes indeed sense to have a way to turn an opam package into a wacoq package; have you looked at the jscoq/wacoq SDK ? Shachar gave a presentation at the Coq workshop which should be in youtube.

Main problem with opam is that it is really a PITA to instrument or to develop properly with it; in many scenarios you want to have a build workspace where you can rebuild jscoq + some addons in a fully incremental way (as to test quickly) ; but indeed, looking forward to have better addon build setup.

[ejgallego]

Maybe Enrico you can give a quick description on how the script is supposed to work so we can see if that will produce the right stuff for jsCoq / waCoq (note that they are unified in 8.16)

deployment URL is hardcoded. I only managed to hardcode a file:///absolutepath or https:// URL in wacoq-bin/src/backend/core.ts it would be nice if one could have the same build be tested locally and remotely

I'm unsure I understood this, but that's a jsCoq issue please open an issue there, we have some improvements (see the PR "towards require.resolve") , but not sure if that will fully fix the problem you see.

[gares]

I see the approach based on dune and composition the main problem, the extra speed is not worth the complexity IMO.
It is not the role of the addons system to decide how packages are built or installed.

I want to package addons from the opam root, where they are installed in a standard way, not from a git checkout of a submodule which clones an upstream repo, superposes it with dune files, etc... to finally package what is in _build/ (which is also in the opam root after installation).

I don't want to maintain extra build systems, at most a simple patch. All the addons above build just fine without the dune overlays. The most tricky one due to the linking problem (I'm on 8.15) is elpi, and the patch is 1 line for an extra -dontlink (to disappear after findlib becomes usable in wacoq) and 2 lines to remove the call to Boot.Env.init (still unclear to me why it is needed, but it is). These I can maintain as part of wacoq addons, since they are specific to it.

If you package from the opam root installation you don't need to recompile .vo files to work on the packaging system, while the current addon setup mixes the two (dune does both the build of the package and the npx packaging).
I don't see why they can't be separated, e.g. move all the npx calls after the facts.
This is how the other installers of the platform are built.

[gares]

deployment URL is hardcoded. I only managed to hardcode a file:///absolutepath or https:// URL in wacoq-bin/src/backend/core.ts it would be nice if one could have the same build be tested locally and remotely

I'm unsure I understood this, but that's a jsCoq issue please open an issue there, we have some improvements (see the PR "towards require.resolve") , but not sure if that will fully fix the problem you see.

It may be because I'm on the 8.15 branch, but wacoq needs to "upload" the coq worker, and the wa binary needs to be addressed somehow. Unfortunately it seems to only like absolute filesystem paths or absolute urls, while one would just want to use relative urls. I don't understand why browsers refuse to fetch from relative urls (there are tons of stackoverflows questions on the topic)

[ejgallego]

Oh I see, I have little idea about the restriction on relative paths (Shachar is the expert for this), but basically in the config options we used to pass the path, which I agree is a bit of a pain.

Tho, it is not hard to have the reference .html code look at the url of the page and set the path to jsCoq initalization properly.

On the topic of how wacoq handles paths, indeed I think the 8.16 / 8.17 branch was also improved.