tweag / tweag/rules_haskell

Support Backpack

Open
#359 0 comments 5 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

P3 type: feature request
Dominant language
Starlark
Stars
279
Forks
93
Avg merge
13d 11h
Merged PRs (30d)
3

Description

This should be fairly straightforward in the case of Bazel. The build is already component oriented, so there's no refactor required like for Cabal, cabal-install and Stack. Cabal supports a fairly elaborate "mixin linking" scheme, that we can simply drop for now. We don't lose expressive power, since everything that can be expressed as mixin linking can also be expressed using the equivalent of Cabal's signatures field, internal libraries and reexported-modules field (see #357). We just need to create (and name) more components (i.e. "rules" in Bazel parlance) than would otherwise be necessary, but that's fine.

So in short, AFAICT we need:

  • Add a new rule attribute for libraries called signatures.
  • Carry the set of signatures associated with targets in their respective providers. Use depsets for this, since signatures are inherited from one library to another.
  • Implement module substitutions, as explained in the Backpack proposal. This means tacking on the correct [M=<M>] etc substitutions to unit id's and passing -instantiated-with arguments. This is explained here.
  • Match modules and signatures before calling GHC.
  • Detect when libraries remain uninstantiated (i.e. have unfilled signatures) after matching. In this case, we can't compile, but should type check and generate interface files (that is, we should pass -fno-code).
  • Detect dependencies that are now fully instantiated after matching, and compile them.
  • Import the Backpack tests found in Cabal's test suite and Bazelify them. This might require #357 and #358 as prereqs for some of the tests.

We don't need package hashes like Cabal does, nor hashes of instantiations tacked on to hashed library names (eek!), because our package names are globally unique within the workspace.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Read the Backpack proposal, especially its GHC section, then inspect the existing library rules and providers. Use Cabal's cabal-testsuite/PackageTests/Backpack tests as the acceptance target, with #357 and #358 as prerequisites where needed. Done means signatures, substitutions, matching, instantiation handling, and Bazelified Backpack tests are supported.

Written by the indexing model from the issue text.

Assessment

Tech stack
haskell
Domain
build-system, compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.