I'm dune-ifying a large project which uses multiple -Q
options for a single library — say -Q foo/bar bedrock.foo -Q baz/quux bedrock.baz
, but with mutual dependencies across bedrock.foo
and bedrock.bar
. IIUC, I understand that support for this is not planned in dune, and I'll have to rearrange source code and logical paths accordingly — or split this into multiple libraries? That's what I'll probably be doing, but I wanted to confirm.
For simplicity, let's ignore the option of splitting into multiple libraries — I know it's possible, but let's say there are valid internal reasons for this setup.
@Paolo Giarrusso we could support that but it'd take time
would be really a single library with multiple binding points, something such as
(coq.theory
(names
(foo/bar as bedrock.foo)
(baz/quux as bedrock.baz))
....)
but looks a bit complex to me, so it'd be good for us to think together was is really going on
is that setup coming due to file generation?
Dune can do much better in this front that make
Something crutial in Dune is to manage the filesystem scan centrally
so that kind of "distributed setup" complicates code a lot as now dune has to merge to compute the list of files
this is necessary remember both to have soundness when a file is deleted and to properly account for generated files
Don't hesitate to open a feature request with a small motivating example, maybe we can do something different that solves the original problem
sorry, nevermind I guess, other things have probably more value (currently: vos/vok
and dune/IDE integration)
[follow-ups moved into https://coq.zulipchat.com/#narrow/stream/240550-Dune-devs-.26-users/topic/vos.2Fvok.20builds)
Last updated: Jun 03 2023 at 18:01 UTC