haskell / haskell/cabal

Need help porting `Custom` build script to `Hooks` build script

Open
#12,344 3 comments 0 reactions 0 assignees View on GitHub
type: user-question
Dominant language
Haskell
Stars
1.7k
Forks
750
Avg merge
4d 3h
Merged PRs (30d)
28

Description

**What is your question?**
As someone unfamiliar with the inner workings of Cabal, I'm having a hard time trying to port my old `Custom` [build script](https://github.com/poscat0x04/shake-fpga/blob/da5511a4b1eea9eb12a3093805316e25ee03591e/src/Distribution/FPGA.hs#L141) to the new `Hooks` build script.

I'll first describe what the old script/hooks does: Basically, I'm trying to integrate verilator into [clash](https://clash-lang.org/) projects to test hardware designs using cabal tests. The hook does the following stuff when invoked during pre-build:

1. Compiles clash design to verilog
2. Runs verilator on verilog to generate a linkable library (as a single .o object file)
3. Generates a Haskell binding to the linkable library (more specifically a single `.hsc` file)
4. Injects suitable linking options as well as a single Haskell module into the `BuildInfo`s of each test component

Steps 1-3 is done using shake to avoid unnecessary recompilation.

Obviously, step 4 is easy with `Hooks` type as you can similarly modify the `BuildInfo` using `preConfComponentHook`s. Steps 1-3 however is where I'm stuck.

I think I should be using pre-build rules, but I don't know how. Like the documentation doesn't even explain most concepts...

**System information**
- `ghc` version 9.12.4

**Additional context**
I've also read the blog post https://well-typed.com/blog/2025/01/cabal-hooks/ but I'm having a hard time adapting it to my use case as this is not a simple preprocessor.

Contributor guide

Open the contributing guide

Research direction

Start with the linked src/Distribution/FPGA.hs build script and the Cabal Hooks documentation, especially preConfComponentHook and pre-build rules. Compare the old Custom workflow with the Hooks API and the linked blog post. Done would be a clear, documented path for handling the three generated build artifacts and component configuration.

Written by the indexing model from the issue text.

Assessment

Tech stack
haskell
Domain
build-system
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.