Build failing due to existence of broken symbolic link (unused in build)
Nobody has claimed this yet.
- Dominant language
- OCaml
- Stars
- 1.9k
- Forks
- 500
- Avg merge
- 15h 21m
- Merged PRs (30d)
- 277
Description
Expected Behavior
Not failing when a broken symbolic link exists (without being used by the current build).
Actual Behavior
I am building a vendored cmake project which itself has vendored thrust, which contains intentionally broken symlinks in its test directories (not involved in present build). This is resulting in failure of the dune rule which is running cmake.
Error: File unavailable:
c/vendor/manifold/src/third_party/thrust/dependencies/libcudacxx/libcxx/test/std/input.output/filesystems/Inputs/static_test_env/bad_symlink
Broken symbolic link
Deleting the symbolic links allows the build to complete (not a satisfying solution as I'd like to not be stuck patching the vendored submodules).
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the vendored CMake project described in the issue and inspect the Dune rule that runs CMake. Trace why the unused broken symbolic link at c/vendor/manifold/src/third_party/thrust/dependencies/libcudacxx/libcxx/test/std/input.output/filesystems/Inputs/static_test_env/bad_symlink is treated as an error; done means the build succeeds without deleting the vendored links.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cmake, ocaml
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100