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

cabal: Add support for empty libraries #2287

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

iteratee
Copy link
Contributor

Previously, an empty library that only exported modules from another library failed to build. Bazel would error out when the .a file wasn't created. These libraries are becoming more common in the Haskell ecosystem, so we need to support them.

There is a straightforward way to handle these libraries. We make the package database the default output. We avoid creating an output file for any libraries if the library is marked as empty. This is all straightforward bazel dependency/output management.

Adjust the cabal wrapper to fix up the package database even in the case that there is no library. Otherwise we end up with an empty package database, which isn't what we're looking for.

Previously, an empty library that only exported modules from another
library failed to build. Bazel would error out when the .a file wasn't
created. These libraries are becoming more common in the Haskell
ecosystem, so we need to support them.

There is a straightforward way to handle these libraries. We make the
package database the default output. We avoid creating an output file
for any libraries if the library is marked as empty. This is all
straightforward bazel dependency/output management.

Adjust the cabal wrapper to fix up the package database even in the case
that there is no library. Otherwise we end up with an empty package
database, which isn't what we're looking for.
@iteratee iteratee requested a review from avdv as a code owner February 13, 2025 17:50
@avdv
Copy link
Member

avdv commented Mar 4, 2025

Thank you, that looks good so far.

It would be nice if this would be usable from stack_snapshot and also from the module extension.

With this in place we should be able to remove the workaround for empty packages here, right?

Could you also add a test case (I was using the nats package to test this after removing that from the empty packages blacklist) please?

This is related to #1458, #1302 and (partially) also #2274 and #2200.

For the last one, we would need to pass through the haddock attribute to the haskell_cabal_libary call from stack_snapshot / the module extension for specific packages, similarly to the empty_library attribute.

This gets a bit tedious over time, especially since Bazel's attr is a bit limited and does not support arbitrary values in dicts, just strings. We would have to add empty_libraries and a disable_haddock list attributes for these... and maybe more in the future.

I was thinking about adding a rule which mimics the cabal attributes and returns a Provider that can be used to pass additional information to the haskell_cabal_library rule. Something along the lines of:

cabal_args = provider(...)

haskell_cabal_args = rule(
  ...
  attrs = {
    "is_empty": "if package is empty",
    ...
  },
  provides = [cabal_args],
)

haskell_cabal_library = rule(
   ...
   attrs = {
     ...

    "args": attr.label(providers = [cabal_args]),
  },
)

_stack_snapshot = repository_rule(
   ....
   attrs = {
     ...

    "package_args": attr.string_keyed_label_dict(providers = [cabal_args]),
  },
)

One could then pass any additional args to the stack_snapshot macro:

stack_snapshot(
   ...
   package_args = {
     "nats": { "is_empty": True },
     "zlib-clib": { "haddock": False },
  }
   ...
)

... which would generate haskell_cabal_args targets for each entry of the given dict and pass the appropriate label to the args attribute of the internal _stack_snapshot repository rule.

WDYT?

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.

2 participants