Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to generating subdir with dynamic_include #10405

Open
rlepigre opened this issue Apr 8, 2024 · 4 comments
Open

Allow to generating subdir with dynamic_include #10405

rlepigre opened this issue Apr 8, 2024 · 4 comments

Comments

@rlepigre
Copy link
Contributor

rlepigre commented Apr 8, 2024

Desired Behavior

Currently, dynamic_include cannot deal with files using subdir. How hard would it be to support it?

Example

The example I have in mind is simple, and involves generating rules that produce Coq files containing the representation of the AST of all the source files of a source tree. So, for each file of the source tree, say dir1/dir2/bla.cpp, I want to produce dir1/dir2/bla.v (and potentially other files as well based on the base name).

Producing these rules is kind of complicated. In our current setup, we use a script that produces a dune.inc file (produced by a wrapper Makefile), that is then included (via include, not dynamic_include). The produced dune.inc relies heavily on subdir (for simplicity, and to not have to recursively include files). Ideally, I'd like to let dune run the script producing dune.inc, and the rely on dynamic_include, to avoid the two-stage build with the Makefile.

@emillon
Copy link
Collaborator

emillon commented Apr 17, 2024

Hi,
Have you tried the second approach in the howto guide? It explains how to encode this kind of "rule scheme". You'll have to change the directory structure a bit but it might work for you.

@rlepigre
Copy link
Contributor Author

I did manage to make things work with a flat directory structure based on something like the guide. However, I do want to preserve a directory structure in the generated files, since the ultimate goal is to build generated files with coq using (include_subdirs qualified). Also, we are working on a directory structure with hundreds of files, so we really can't just have a single directory. The easiest way to make things work as I intend really seems to rely on generating rules wrapped by some subdir stanzas reflecting the source tree.

Would that help if I provided an example of what we'd like to do?

@ejgallego
Copy link
Collaborator

Unfortunately, unless you copy the sources to other directory, there is indeed a cycle problem in the way dune load rules I think, that is to say, if you have:

tests/
tests/t1/...
tests/t2/...

etc... and you want to generate an include file for the tests, you'll need to add (source_tree tests) to the deps of your program, however that would lead to a cycle with the current loading rule I think.

@rlepigre
Copy link
Contributor Author

In my experiment I do copy the sources to another directory, what I mean with a flat directory structure is that the source folder for which I want to generate rules itself has sub-folders. And ideally, I could handle all these subfolders with a single generated dune file that relies on (subdir ...).

Halbaroth added a commit to Halbaroth/alt-ergo that referenced this issue Aug 8, 2024
This PR uses the new feature `dynamic_include` to include our generated
file `dune.inc`.

Pros:
- We do not upstream `dune.inc` anymore!
- The output of `dune.inc` depends on the plateform. This is the main
  motivation of this PR because Windows does not use the convention for
  path.

Cons:
- We need `Dune > 3.14`
- We cannot use the stanza `subdir` in `dune.inc`, which means we have
  to ensure we do not use twice the same name for two tests even if
  there are not in the same directory. See issue
  ocaml/dune#10405
Halbaroth added a commit to Halbaroth/alt-ergo that referenced this issue Aug 9, 2024
This PR uses the new feature `dynamic_include` to include our generated
file `dune.inc`.

Pros:
- We do not upstream `dune.inc` anymore!
- The output of `dune.inc` depends on the plateform. This is the main
  motivation of this PR because Windows does not use the convention for
  path.

Cons:
- We need `Dune > 3.14`
- We cannot use the stanza `subdir` in `dune.inc`, which means we have
  to ensure we do not use twice the same name for two tests even if
  there are not in the same directory. See issue
  ocaml/dune#10405
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants