Is there a (not too complex) way to have jbuilder successfully build a small project relying on ppx_deriving?
“not too complex”: because I’ll do it with ocamlbuild if it appears to be simpler
I tried to add (preprocess (pps (ppx_deriving.enum))) to my library, but when compiling the relevant module, the functions that should be generated by ppx_deriving are not found.
As far as I can tell - no. I gave it a go to make ppx_deriving work with jbuilder a few weeks back https://github.com/whitequark/ppx_deriving/pull/135. However, due to time constraints I had to abandon my attempt. I am guessing ppx_deriving plugin based design + omp has something to do with it.
I’d like to use ppx_deriving_yojson with jbuilder. I’ve tried pinning ppx_deriving to ppx_deriving#141 as suggested, but my project still fails to compile:
Error: Attribute `deriving' was not used
Has anybody successfully used ppx_deriving with jbuilder? Would greatly appreciate more details on how to get jbuilder working with ppx_deriving_yojson (or another ppx_deriving-plugin).
I’m running into something which I think is an instance of this issue, but I’m not sure. I’m using a jbuild file which has (preprocess (pps (ppx_jane ppx_deriving.std))), but when running jbuilder build @install I get errors such as the following for eq and enum:
ppx lib/Frenetic_NetKAT.pp.ml (exit 1)
(cd _build/default && ./.ppx/ppx_jane+ppx_deriving.std/ppx.exe --dump-ast --cookie 'library-name="frenetic"' -o lib/Frenetic_NetKAT.pp.ml --impl lib/Frenetic_NetKAT.ml)
File "lib/Frenetic_NetKAT.ml", line 8, characters 55-72:
Error: ppx_type_conv: 'eq' is not a supported type type-conv generator
Is this the same issue as previously described in the thread?
If you want to use ppx_deriving in the mean time, with pds, one can do deps = ["ppx_deriving.blah"] or deps = ["ppx_deriving_yojson"], although it applies to a whole project rather than just to specific source files.
I wanted the same: ppx_deriving works with jbuilder now, but you’ll need ppx_deriving_yojson with this change (pin or wait for it to get merged/released) ppx_deriving_yojson#60. With that, it works now!
@ttamttam I refactored the handling of ppx rewriters in dune. Before the knowledge of a few ppx projects and their behavior was hardcoded in jbuilder. It wasn’t great as it made the whole system quite rigid. In particular new features had to be synchronized between jbuilder, ocaml-migrate-parsetree, ppxlib and ppx_driver which was a lot of hassle.
With the new system, dune has a generic support for ppx drivers and projects such as ocaml-migrate-parsetree or ppxlib simply declare themselves as ppx drivers. In order to ensure backward compatibility, this new system is only activated when you use a dune file. When using a jbuild file it is still the old system with hardcoded values.
Now, in order to use the new system, ocaml-migrate-parsetree and ppxlib must declare themselves as ppx drivers. The released versions of ocaml-migrate-parsetree and ppxlib already have the relevant information in their jbuild file to declare themselves as ppx drivers. However, only dune will read this information and in particular copy it to the installation directory. This means that if ocaml-migrate-parsetree was build and installed with jbuilder <= 1.0+beta20, then dune cannot see that ocaml-migrate-parsetree is a driver.
Forcing a resintallation of ocaml-migrate-parsetree via opam reinstall ocaml-migrate-parsetree will fix the issue.
See above. The message is pretty clear. I just should have done what was written: upgrade or reinstall. Maybe, it can be improved by quoting the two commands to be tried (at the moment, I did not realize opam had a ‘reinstall’ sub-command).
Thinking about this again, making ocaml-migrate-parsetree and ppxlib explicitly depend on dune in opam should fix this issue. I’m not in front of a computer today but if someone could do it that would be cool
A few versions of these two packages are marked as incompatible with dune, but the latest versions of both are compatible with dune. Changing the dependency from jbuilder to dune for these latter ones should do.
While that is fine, this is going to cause a super massive amount of recompilation for downstream users. As virtually any package is going to depend on ppxlib and omp. I suppose that it can’t be helped and that the correctness is far more important here. What would be nice if opam was somewhat smarter about reinstallation. If the builds are deterministic it should be able to trigger downstream reinstall for cases when the artifacts for omp/ppxlib are going to differ.
PS: ppx_inline_test should need a similar change as well then.
Unfortunately there is not much opam can do here: when build ant installed by dune, the ocaml-migrate-parsetree.dune file is different compared to when built and installed by jbuilder. opam cannot know whether this change matters or not for reverse dependencies of omp so it will always need to rebuild them.
Only Dune can do something here: once we’ll have clould builds, we could enable a shared artefact cache for opam builds and then these reinstallations will be really fast.
File "dune", line 3, characters 18-37:
3 | (preprocess (pps (ppx_deriving.show))))
^^^^^^^^^^^^^^^^^^^
Error: Atom or quoted string expected
Removing the parentheses doesn’t help:
$ dune build test.exe
File "dune", line 3, characters 13-36:
3 | (preprocess (pps ppx_deriving.show)))
^^^^^^^^^^^^^^^^^^^^^^^
Error: No ppx driver were found. It seems that ppx_deriving.show is not
compatible with Dune. Examples of ppx rewriters that are compatible with Dune
are ones using ocaml-migrate-parsetree, ppxlib or ppx_driver.
Notice that the second error is not the same as the first one. The second snippet is correct, and should work, but maybe your version of ppx_deriving is an oldish one? I think support for dune was added last november or so.