I’m inside a large project with many internal packages. I just want to check/build one of the package. I’ve tried the following while inside the package folder containing the dune file:
run dune build @./check
the same command but with --root .
the first throws compile errors of packages that depend on the package I’m trying to build/check, which is what I want to avoid, the second one tells me that I’m missing an .opam at the root (duh, since the .opam files of all the internal packages are all dumped at the root of the project, which I’ve now changed)
--only-packages=PACKAGES
Ignore stanzas referring to a package that is not in PACKAGES.
PACKAGES is a comma-separated list of package names. Note that this
has the same effect as deleting the relevant stanzas from dune
files. It is mostly meant for releases. During development, it is
likely that what you want instead is to build a particular
<package>.install target.
So it sounds like dune build mypackage.install may work, and dune build --only-packages=mypackage @check may also work.
To answer this in more details I tried to find an explanation of what a dune “target” is and what the valid syntax of targets is, but I was unable to find this in the dune documentation – I would have expected to find a 'Targets" subsection in the section on General concepts.
I’ve settled on passing --only-packages for now, but it needs the entire list of dependencies which is quite tedious… I can keep on trying to compile and add whatever missing package the compiler throws at me until the whole command works, which is something I guess
EDIT: I actually think that the command actually works, it’s just that I had wrongly assumed that some transitive dependencies wouldn’t be there. On a different note dune build @./check doesn’t seem to work as intended (it returns a clean output where dune build .` returns compiler errors
Your reply leaves me a bit confused as to what works and what doesn’t (and what we mean by “works” for each command, what would be the expected behavior). Given that this sounds like a reasonably natural question for multi-package repositories, it may be worth clarifying in the interest of people finding this thread in the future.