-
Notifications
You must be signed in to change notification settings - Fork 81
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
rules_haskell is incompatible with Bazel's new "trim_test_configuration" default setting #1536
Comments
There's some disagreement on whether this constitutes a Bazel bug or a problem in rules_haskell that was unearthed by the recent changes. |
@fweikert Thanks for raising this and for repro. I reran the repro with the following debugging code in place: diff --git a/haskell/private/cc_libraries.bzl b/haskell/private/cc_libraries.bzl
index 3ac12fef..2b36ca9c 100644
--- a/haskell/private/cc_libraries.bzl
+++ b/haskell/private/cc_libraries.bzl
@@ -43,6 +43,7 @@ def get_cc_libraries(cc_libraries_info, libraries_to_link):
list of LibraryToLink, C libraries.
"""
+ print("!!! get_cc_libraries", "".join(["\n {}".format(k) for k in cc_libraries_info.libraries.keys()]))
return [
lib_to_link
for lib_to_link in libraries_to_link The output is
The failing code uses a struct over For context, the whole thing is part of a compatibility layer between Bazel's way of handling C libraries and what the Haskell compiler GHC expects. See #1241 and #1256 for details. In short, we generate symlinks for static libraries in an aspect to replicate Bazel's mangling of dynamic libraries, because GHC expects static and dynamic libraries to have the same name. We then keep a mapping from original Perhaps using |
The function `cc_library_key` generates the dictionary keys by which `LibLibraryToLink` are mapped to their corresponding `HaskellCcLibraryInfo`. Before this used a `struct` over `None` or `File` objects. This changes uses `None` or `string` instead, where `string` is the `.path` attribute of the `File` object. Using a `File` object in a dictionary key fails if the `File` object used at lookup time is semantically the same, but has a different identity due to implementation details in Bazel. Closes #1536
cc @sdtwigg as expert |
The function `cc_library_key` generates the dictionary keys by which `LibLibraryToLink` are mapped to their corresponding `HaskellCcLibraryInfo`. Before this used a `struct` over `None` or `File` objects. This changes uses `None` or `string` instead, where `string` is the `.path` attribute of the `File` object. Using a `File` object in a dictionary key fails if the `File` object used at lookup time is semantically the same, but has a different identity due to implementation details in Bazel. Closes #1536
Describe the bug
Using a Bazel binary built at commit bazelbuild/bazel@ebac27e or later will crash certain rules_haskell targets with the following error:
To Reproduce
USE_BAZEL_VERSION="last_green" bazelisk build //tests/binary-with-sysdeps:binary-with-sysdeps
Expected behavior
Build succeeds
Environment
Additional context
--notrim_test_configuration
to Bazel (proof: Bazel CI: Downstream projects broken due to the flip of trim_test_configuration bazelbuild/bazel#13328 (comment)).cc @sdtwigg
The text was updated successfully, but these errors were encountered: