Open kit-ty-kate opened 1 year ago
I think this is the same as #4814 and https://github.com/ocaml/dune/pull/7419, i.e. -p
isn't actually taken into account for these commands.
Actually I think this is a bit more complicated than that: I think this is actually an instance of https://github.com/ocaml/dune/issues/6830, where executables in vendored dirs are built because they might need to be executed.
That sounds about right. dune top -p
has an effect and works as expected, except when it is in presence of a vendored executable.
where executables in vendored dirs are built because they might need to be executed.
In this case though the executable is not built. Here is the build log after dune clean && dune top -p a
with the test case above:
$ (cd _build/default && /home/kit_ty_kate/.opam/default/bin/ocamlc.opt -w -40 -w -49 -nopervasives -nostdlib -g -bin-annot -I a/.a.objs/byte -no-alias-deps -o a/.a.objs/byte/a.cmo -c -impl a/a.ml-gen)
$ (cd _build/default && /home/kit_ty_kate/.opam/default/bin/ocamlc.opt -w -40 -g -a -o a/a.cma a/.a.objs/byte/a.cmo)
However if base is installed, the same command will return:
I think this is because of:
match libs with
| Error () -> (acc, pps)
| Ok libs ->
List.fold_left libs ~init:(acc, pps) ~f:(fun (acc, pps) lib ->
In other words, if we are unable to find or load a dependency for whatever reason, we keep going.
Expected Behavior
For
dune top -p <pkg>
to not pull unrelated dependenciesActual Behavior
dune top -p <pkg>
pulls unrelated dependenciesReproduction
If
base
is not installed on your system,dune top -p a
will return the expected:However if
base
is installed, the same command will return:Specifications
dune
(output ofdune --version
): 3.7.1ocaml
(output ofocamlc --version
): 5.0.0