search

ocaml-ppx / ppxlib

Base library and tools for ppx rewriters
MIT License
243 stars 94 forks source link

ppxlib and ocamlfind: looks like code_path is broken ? #500

Open chetmurthy opened 3 weeks ago

chetmurthy commented 3 weeks ago

While preparing an OPAM package for release, I found a problem with ppxlib. My package depends on ppx_deriving, and between versions 5.2.1 and 6.0.2, something changed that has affected its behaviour. In short, if you build the ppx_deriving test in https://github.com/ocaml-ppx/ppx_deriving/blob/master/src_test/show/test_deriving_show.cppo.ml

  1. with dune, you will get correct behaviour from the test -- in tests like test_variant ( https://github.com/ocaml-ppx/ppx_deriving/blob/32f7c31ecfcbca6d53f3655a00e8852f4751123e/src_test/show/test_deriving_show.cppo.ml#L45 ) the generated code will produce a string that contains the module-path

  2. with ocamlfind, you will get incorrect behaviour: the generated code will produce a string that DOES NOT contain the module-path. So instead of Test_deriving_show.RFoo you will get RFoo.

I don't know whether building OCaml code using ocamlfind is supported anymore, but if it's supposed to be, then it seems to me that one should be able to use PPX rewriters from ocamlfind, and get the same results that one does when using them from dune.

chetmurthy commented 3 weeks ago

I posted about this here: https://discuss.ocaml.org/t/ann-ppx-deriving-6-0-2-and-ppx-deriving-yojson-3-8-0/14750

There is a smaller example (extracted from the above-mentioned unit-test), along with output, that shows the problem.

I hope it's clear that at ppx_deriving.5.2.1, building with ocamlfind produces a test that works correctly, and that at 6.0.2, that same build produces a test that fails, b/c the module-paths inferred from filenames are empty.

NathanReb commented 3 weeks ago

Thanks for reporting this! I myself noticed this behaviour while releasing ppx_deriving and ppx_deriving_yojson.

I'll use your repro to add tests and debug this!