Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix issue with long path names. #152

Merged
merged 1 commit into from
Oct 18, 2023
Merged

Conversation

martis42
Copy link
Owner

@martis42 martis42 commented Oct 18, 2023

In deeply nested workspace and/or long target names the paths for the various DWYU artifacts can become quite long. At some point they are too large for Bazel and the OS to handle and consequently DWYU fails.

We fix this by:

  • We use only the name of the to be analyzed target instead of its full label as prefix for the DWYU artifacts. The artifacts are generated inside bazel-out in the package location of the to be analyzed target and thus the name is sufficient as suffix to guarantee unique results.
  • For the DWYU artifacts depending on dependencies we no longer use the dependency label as path suffix, but instead use the hash of the label. This gives us an upper bound on the max length of the generated file names while still making name collision quite unlikely. That the names are less verbose does not matter. If one wants to debug, the name of the dependency is contained in the file either way.

Resolves #151

In deeply nested workspace and/or long target names the paths for the
various DWYU artifacts can become quite long. At some point they are too
large for Bazel and the OS to handle and consequently DWYU fails.

We fix this by:
- We use only the name of the to be analyzed target instead of its full
  label as prefix for the DWYU artifacts. The artifacts are generated inside
  bazel-out in the package location of the to be analyzed target and thus
  the name is sufficient as suffix to guarantee unique results.
- For the DWYU artifacts depending on dependencies we no longer use the
  dependency label as path suffix, but instead use the hash of the label.
  This gives us an upper bound on the max length of the generated file names
  while still making name collision quite unlikely. That the names are less
  verbose does not matter. If one wants to debug, the name of the dependency
  is contained in the file either way.
@martis42 martis42 merged commit 631de30 into main Oct 18, 2023
4 checks passed
@martis42 martis42 deleted the limit_max_path_lenth_of_artifacts branch October 18, 2023 19:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Action failed, file name to long
1 participant