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

Allow reexporting a package from a haskell_library #1008

Merged
merged 6 commits into from
Aug 5, 2019
Merged

Conversation

thufschmitt
Copy link
Contributor

This is the re-opening of #757 (because github doesn't allow me to directly reopen it)

I eventually found the time to finish this.

I didn't reuse the exports field since I find it a bit disturbing to suddenly change the meaning of an existing attribute, so the field is called package_reexports instead.

So the semantics now are that if a rule foo has package_reexports = [ "bar ], then

  • foo will depend on bar (as if it was in its deps field)
  • Any rule that (directly) depends on foo will see bar as if it was in its dependencies
  • Running foo@repl will load both the modules of foo and bar

@mboes
Copy link
Member

mboes commented Jul 26, 2019

I didn't reuse the exports field since I find it a bit disturbing to suddenly change the meaning of an existing attribute, so the field is called package_reexports instead.

As we discussed, no one is using this field, so go ahead and reuse it.

@thufschmitt
Copy link
Contributor Author

I've renamed the old exports attribute to module_exports and that one to exports

Théophane Hufschmitt added 5 commits August 2, 2019 08:01
Add a new `package_reexports` argument to `haskell_library` such that if
a rule `foo` has `bar` in its `package_reexports`, every package that
depends on `foo` will also implicitely depend on `bar`
We have two choices for the name of this field: follow Bazel
convention or follow Cabal convention. We would normally do the
former, but I would argue that there is no Bazel precedent in this
case. For package reexports, we have the `exports` field like in Java.
We could use the same precedent for module reexports, but for the
following qualitatitve differences:

* module reexports don't have the same type. We have to map labels for
  packages to reexport specs.
* Module reexports aren't about targets per say, but rather parts of
  a target (aka a "package" in Cabal parlance). The rules don't really
  know about modules, only the compiler does.

So for lack of established Bazel precedent, we follow Cabal precedent.
This has the advantage that attributes that handle modules are all
named the same way (`hidden_modules`, `reexported_modules`, etc).
@mboes mboes added the merge-queue merge on green CI label Aug 5, 2019
@mergify mergify bot merged commit 9d447e7 into master Aug 5, 2019
@mergify mergify bot deleted the haskell_group branch August 5, 2019 07:51
@mergify mergify bot removed the merge-queue merge on green CI label Aug 5, 2019
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