Stream: Dune devs & users

Topic: Specific warnings for extracted files


view this post on Zulip Jean-Christophe Léchenet (Apr 05 2024 at 08:26):

Hi everyone,

I'm having a look on how much work is needed to port Jasmin to a dune-only build. I am new to dune, so I hope I did not miss something obvious. For now, it uses dune only for the OCaml part. Jasmin have Coq files extracted into OCaml, but everything works fine (once I list all the modules produced by the extraction in the dune file).

The part that bothers me is that I do not understand how to have a different set of warnings for manually written OCaml files (where we want to be strict) and the ones coming from extraction (the generated code often produces some warnings, so we want to be more lenient). Per-file flag is a long-awaited feature, but it is still not there (strangely, some logic to support it was introduced in a PR long ago, but if I am not mistaken it is not used anywhere in dune). One way is to use a different stanza to build a library from the extracted files, but I do not think it makes sense semantically to create this internal library just to circumvent what seems to be a limitation coming from dune. Another solution, proposed in several places, is to add an annotation [@@@ocaml.warning _] at the top of every extracted file. But even that I do not know how to do in dune without listing explicitly all the files. I have already written the list manually in the dune file taking care of the extraction, I do not want to do it twice. It does not seem possible to apply some preprocessing for all the files in a given subfolder for instance. And even asking extraction itself to add the annotation does not seem possible with the extraction directives we have.

I ran out of ideas. Does someone have any hint on how I could solve my problem?

view this post on Zulip Rodolphe Lepigre (Apr 05 2024 at 11:20):

What if you split the code into several libraries? I mean, if the extracted code formed an independent OCaml library (via a (library ...) thingy), then you could set specific flags for this library. Or is such a split not possible in your case?

view this post on Zulip Jean-Christophe Léchenet (Apr 05 2024 at 11:47):

First, I think this split would be artificial, in the sense it would only be there to comply with the constraints of the build system (this is what I meant when I wrote "One way is to use a different stanza to build a library from the extracted files, but I do not think it makes sense semantically to create this internal library just to circumvent what seems to be a limitation coming from dune."). Second, I am not even sure it is possible, since extraction uses Extract Constant directives, which makes the extracted code depend on the OCaml code.

view this post on Zulip Gaëtan Gilbert (Apr 05 2024 at 11:49):

But even that I do not know how to do in dune without listing explicitly all the files

per file flags wouldn't change that

view this post on Zulip Jean-Christophe Léchenet (Apr 05 2024 at 11:51):

Hum, I assumed per_file could also use glob, but maybe not.

view this post on Zulip Gaëtan Gilbert (Apr 05 2024 at 11:52):

actually I think you're right to assume that

view this post on Zulip Gaëtan Gilbert (Apr 05 2024 at 11:52):

I just didn't think of it

view this post on Zulip Emilio Jesús Gallego Arias (Apr 05 2024 at 14:22):

Indeed, as of today dune doesn't support per-file flags easily, and I think you've identified the workarounds.

The main reason this wasn't done is that actually the use case is not very common, and the patch in Dune is not so straightforward: as of today, flags can be computed from a library + context, so adding a flag recomputation for each file is a deeper change that can require lots of refactoring (and care with the performance).

But I'm sure any advance in this area would be welcome upstream.

view this post on Zulip Li-yao (Apr 05 2024 at 14:40):

For the workaround using separate libraries, you may have to separate it in three: one library that the extracted modules depend on, the extracted modules, and the rest. The "artificiality" of it doesn't seem that objectionable to me.


Last updated: May 25 2024 at 21:01 UTC