test: pps runtime libs reach melange compile rule

[robinbb]

Pins that a (melange.emit ...) stanza preprocessing with a ppx whose (ppx_runtime_libraries ...) is non-empty includes globs over the runtime lib's .cmi/.cmj melange objdir in the compile-rule dep set — even though no source names the runtime lib syntactically.

Melange compile rules bypass per-module narrowing today (can_filter = false in module_compilation.ml); the property holds via the wide cctx glob. Forward-looking guard if narrowing ever extends to melange.

[Copilot]

Pull request overview

Adds a black-box cram test ensuring that a melange.emit stanza preprocessed with a ppx whose ppx_runtime_libraries includes a melange library results in the melange compile rule depending (via globs) on the runtime library's .cmi/.cmj melange objdir, even when no melange source syntactically references that runtime library.

Changes:

• New cram test melange-pps-runtime-libs.t that sets up a melange runtime library, a ppx rewriter declaring it as a ppx_runtime_libraries, and a melange.emit consumer, then asserts via dune rules --deps + jq that the compile rule has the expected globs on the runtime lib's melange objdir.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

[anmonteiro]

I'm curious why the filtering doesn't apply to Melange? can i read about the limitations somewhere?

[Alizter]

@anmonteiro I don't think there was a technical reason other than being unfamiliar with the melange rules. @robinbb would it simplify the filtering if we extended it to melange?

[robinbb]

@anmonteiro @Alizter Yes, that's right. I would prefer not to have these special-case code paths for Melange, but since I do know of a test suite against which I can assert that I have not broken anything, and because I do not know the Melange special cases (or absence of special cases) myself, I am trying to carefully preserve the Melange behaviour. Also, there was already some Melange special-casing in the code prior to this work.

I would love to partner with you, @anmonteiro, if you have some time for it, to improve the handling of Melange. (However, it can come after the 9-layer PR #14492, as we need not block on it, IMO.)

[anmonteiro]

@robinbb that sounds great!

There might be some stuff around the .js emission in what they require, but melange compilation should rely only on ocamldep -- my mental model is that dependency filtering can work for it.

[robinbb]

@anmonteiro Okay, good start. What might break if we get it wrong? Is there a body of source code that we can build with the old/new Dune to check to see if we have the logic right?

[anmonteiro]

usually the melange repository itself can be pretty representative, since it builds its own runtime libs with cross-module optimizations and the entire runtime testsuite.

Usually if i want to get more confidence, I'll run it through the entire package set in nix-overlays, which should have most publicly available packages.