`@bios` outputs source files in Bazel execroot (sandbox)
To Reproduce In rules_haskell_tests:
bazel run //tests:hie-bios@bios
It outputs source files from Bazel execution root:
...
/private/var/tmp/_bazel_adrienpiquerez/c215c24f6194429899826b2b5022c4c2/execroot/rules_haskell_tests/tests/RunTests.hs
/private/var/tmp/_bazel_adrienpiquerez/c215c24f6194429899826b2b5022c4c2/execroot/rules_haskell_tests/bazel-out/darwin_arm64-fastbuild/bin/tests/generated-modules/src/BinModule.hs
/private/var/tmp/_bazel_adrienpiquerez/c215c24f6194429899826b2b5022c4c2/execroot/rules_haskell_tests/bazel-out/darwin_arm64-fastbuild/bin/tests/generated-modules/src/GenModule.hs
/private/var/tmp/_bazel_adrienpiquerez/c215c24f6194429899826b2b5022c4c2/execroot/rules_haskell_tests/tests/integration_testing/IntegrationTesting.hs
/private/var/tmp/_bazel_adrienpiquerez/c215c24f6194429899826b2b5022c4c2/execroot/rules_haskell_tests/tests/binary-with-lib/Main.hs
/private/var/tmp/_bazel_adrienpiquerez/c215c24f6194429899826b2b5022c4c2/execroot/rules_haskell_tests/tests/binary-with-lib/src/Lib.hs
Expected behavior
It should output source files from the Bazel workspace.
The problem is that neither HLS nor VSCode know those source files are hard links to the workspace source files. Consequently, they report errors in the sandboxed source files, instead of the workspace source files on which I am working, and code navigation redirects to the sandboxed source files too. I end up having two copies of the same file opened, possibly with different unsaved edits.
Environment
- OS name + version: MacOS Sequoia 15.6
- Bazel version: 6.5.0
- Version of the rules: 1.0
Additional context
I am working on the daml codebase. Is this hie-bios output working for others? Do we miss any configuration to make this work for us?
Looking at the bazel-bin/tests/hie-bios@bios, it seems that it outputs source files from execroot on purpose:
$ cat bazel-bin/tests/hie-bios@bios
...
#!/usr/bin/env bash
...
# shellcheck disable=SC1083
SCRIPT_REL=bazel-out/darwin_arm64-fastbuild/bin/tests/hie-bios-hie-bios@bios-script
SCRIPT_ABS="$(rlocation rules_haskell_tests/tests/hie-bios-hie-bios@bios-script)"
# shellcheck disable=SC2034
RULES_HASKELL_EXEC_ROOT=${SCRIPT_ABS%/"$SCRIPT_REL"}
...
$RULES_HASKELL_EXEC_ROOT/tests/RunTests.hs
$RULES_HASKELL_EXEC_ROOT/bazel-out/darwin_arm64-fastbuild/bin/tests/generated-modules/src/BinModule.hs
$RULES_HASKELL_EXEC_ROOT/bazel-out/darwin_arm64-fastbuild/bin/tests/generated-modules/src/GenModule.hs
$RULES_HASKELL_EXEC_ROOT/tests/integration_testing/IntegrationTesting.hs
$RULES_HASKELL_EXEC_ROOT/tests/binary-with-lib/Main.hs
$RULES_HASKELL_EXEC_ROOT/tests/binary-with-lib/src/Lib.hs"
This seems to be intended. How can it work in integration with HLS and an IDE like VSCode?
Hi @adrien-piquerez-da,
thank you for opening this issue. I see you already found a workaround, which is similar to how we have integrated @bios output for IDE support:
bazel run "${target[0]}@repl@bios" | while read -r line; do
# The bios script references files in the execroot bazel folder.
#
# We need to re-map the files back to to the workspace directory since
# the IDE should not try to open files inside of the execroot (and the
# hls would not work there).
#
# Also, hie-bios / ghcide needs to be able to locate files in the search
# path (given with -i flags). This is how it learns about the source files
# it should track, otherwise it will not be able to load modules from the
# same component. So we also have to map the search paths referencing
# the execroot back to the workspace too.
if [[ "$line" = "$execroot/"* ]]; then
relpath="${line#"$execroot/"}"
if [[ -f "$relpath" ]]; then
echo "$relpath"
continue
fi
elif [[ "$line" = "-i$execroot/"* ]]; then
relpath="${line#-i"$execroot"/}"
if [[ -d "$relpath" ]]; then
echo "-i$relpath"
continue
fi
fi
echo "$line"
done
(this is from https://github.com/avdv/replay/blob/main/.hie-bios)
HTH