@GrahamcOfBorg build ocamlPackages.elpi

The problem is that the version of ppxlib you use is too old, even if I don't specify any version in the opam file. I'll update the opam file upstream.

You use 0.8.x while I need >= 0.12.0

Then #87694 should fix this.

@gares @vbgl I rebased on #87694 for the test, and it remove one error message out of three.
cf https://gist.github.com/CohenCyril/0bf93ea4c36d0282b207cb334436251d

@GrahamcOfBorg build ocamlPackages.elpi

@vbgl commit 20b558a works for me, I had to bump up the versions of ocaml-migrate-parsetree and ppxfind, should I do it globally or via overrides? in a separate PR or in this one?

If the changes are independent, separate PRs I find easier to review.

Updating ppxfind might break a few things.

After quick testing, it seems that OMP and ppxfind should be both updated at once. Also, to avoid breaking 2⁸ packages, you may need #87824.

@CohenCyril , is the bump of ppxfind really needed?

@CohenCyril , is the bump of ppxfind really needed?

it was needed for OMP 1.7 but maybe not for 1.6 let me check!

@CohenCyril , is the bump of ppxfind really needed?

it was needed for OMP 1.7 but maybe not for 1.6 let me check!

nop... (https://github.com/jeremiedimino/ppxfind/releases/tag/1.4)

There is no need for the complexity of several versions of OMP and ppxfind.

Good to know, I did not know how to check whether a change like #88087 broke stuff, so I worked-around. I will update this PR as soon as #88087 is merged. But anyway I am still waiting for coq-elpi's next release before changing this pr to "ready".

This is draft PR ready to be promoted to a real PR? It seems so

@CohenCyril I recommend fetching the dune-release tarball, i.e. something like

{
  src = fetchzip {
    url = "https://github.com/LPCIC/elpi/releases/download/v${version}/elpi-v${version}.tbz";
    sha256 = "15hamy9ifr05kczadwh3yj2gmr12a9z1jwppmp5yrns0vykjbj76";
}

so that elpi -version works correctly.

It's also a bit depressing that this PR has to move away from using buildDunePackage, with all the complexity that calling mkDerivation directly entails.

@gares

This is draft PR ready to be promoted to a real PR? It seems so

Not until we release hiearchy builder (I faked the existence of 0.9.1+alpha1 here)
EDIT: And not until #88087 is merged.

@Zimmi48

@CohenCyril I recommend fetching the dune-release tarball, i.e. something like

I will try it works indeed (EDIT: I just had to fix the homepage which used to be provided by fetchFromGithub)

It's also a bit depressing that this PR has to move away from using buildDunePackage, with all the complexity that calling mkDerivation directly entails.

I agree,... @gares what difference would it make if we called dune directly rather than make?

In commit 25b66e1 I tried and I saw no problem. Would a problem occur on different uses that coq-elpi and hierarchy-builder?

@GrahamcOfBorg build ocamlPackage.elpi coqPackages_8_11.coq-elpi coqPackages_8_11.hierarchy-builder

I agree,... @gares what difference would it make if we called dune directly rather than make?

The only different thing is that in Makefile I hack elpi.install since it wants to install ppxfindcache_* which are internal binaries (it won't really hurt having them installed, but it sucks). I can't make them internal otherwise dune does not build them before calling the ppx rules that use these binaries. I've never figured out if it is a real bug, or if I'm doing something wrong. I may even had open a bug on dune and forgot.

How does nix compute which files are part of a package?

How does nix compute which files are part of a package?

everything that is copied to the $out directory is part of the package.

hum, then you can probably call dune and only keep the elpi binary (no other binary in $out/bin)

alright!

It's green

hum, then you can probably call dune and only keep the elpi binary (no other binary in $out/bin)

@gares, the contents of $out/bin is elpi, ppxfindcache_deriving_std and ppxfindcache_elpi_trace_deriving_std.
If I try to remove anything, coq-elpi does not compile anymore. Is it normal?

these binaries are not used by coq-elpi Makefile. So it is fishy. (Also, I remove them in Opam...)

You can leave them there, they won't hurt. They are just useless.

@GrahamcOfBorg build ocamlPackage.elpi coqPackages_8_11.coq-elpi coqPackages_8_11.hierarchy-builder

@vbgl all green 👍

@GrahamcOfBorg build coqPackages_8_11.hierarchy-builder