[Well-Typed Blog] An introduction to Cabal Hooks for package authors

Links
1
19 Likes
2

Finally! Down with the (old fashion) Custom setups!

4 Likes
3

Benefits for HLS were mentioned but not described; can someone help me understand what benefits will there be?

4

I think this is the most enlightening bit, taken from the tech proposal:

By way of example, consider an IDE backend like HLS. An IDE wants to be the build system (and compiler) itself, not for any final artefacts but for the interactive analysis of all the source code involved. It wants to prepare (i.e. configure) all of the packages in the project in advance of building any of them, and wants to find all the source files and compiler configuration needed to compile the packages. This is incompatible with a set of opaque per-package build systems, each of which is allowed to assume all dependencies already exist, and which can only be commanded to build artefacts.

Tech Proposal

5 Likes
5

What is the migration story for packages that currently use build-type: Custom? The article mentions the Cabal Hooks overlay, which shows how existing build-type: Custom packages could be patched to use Hooks instead. At what point can packages start switching over without worrying about backwards compatibility concerns?

1 Like
6

Good question. Packages switching over need to use cabal-version: 3.14, which currently means the very latest Cabal/cabal-install releases. That’s not such a big deal for applications (since upgrading cabal-install is not hard, and one can continue using an older GHC) but I imagine many libraries will not want to force all their users onto cabal-version: 3.14 immediately. Beyond that, it’s really a choice for library authors as to how old cabal-installs they want to support.

Overall, we expect the transition is going to be fairly drawn out. There is a bit of a chicken-and-egg problem because there isn’t huge motivation for existing libraries to switch until the tooling can take advantage of the new design, but the tooling is still constrained by the need to support libraries that use the old design. But at least the transition can start now! Then hopefully in a year or two cabal-version: 3.14 will have been around for long enough for libraries to use it freely, and we’ll have been able to land more improvements to cabal-install/HLS that benefit build-type: Hooks users, so there will be additional motivation to switch.

7 Likes
7

As discussed at Migration guide for SetupHooks, especially hookedPreProcessors · Issue #10207 · haskell/cabal · GitHub, I’d really love to have a high-level helper for preprocessors. Not only “Custom pre-processors” section is much more verbose than hookedPreProcessors used to be, but it’s likely to be very fragile to upgrade in future, because it involves lots of Cabal API, which is not necessarily very stable.

1 Like
8

Thank you very much @adamgundry for posting this article, I’m in the middle of writing such a hook in order to copy a .a static library to the build directory of a cabal package. The documentation for extra-bundled-libraries says:

Note that you are under the obligation to produce those libraries in the build directory (e.g. via a custom setup)

Here’s the hook:


preBuildRules :: PreBuildComponentInputs -> RulesM ()
preBuildRules pbci = do
  let verbosity = Hooks.buildingWhatVerbosity $ pbci.buildingWhat
  let sourceDir = Path.makeSymbolicPath "."
  let destDir = buildDir pbci.localBuildInfo
  let icedLibrary  = Location sourceDir ( Path.makeRelativePathEx "libiced_hs.a" )
  let destinationPath = (Path.getSymbolicPath destDir) <> "/libCiced.a"
  let destinationLocation = Location destDir (Path.makeRelativePathEx "libCiced.a")
  let command = Hooks.mkCommand (static Dict) (static moveLibIced) ("libiced_hs.a", destinationPath) 
  libIcedArchiveExists <- liftIO $ doesFileExist "libiced_hs.a"
  unless libIcedArchiveExists $
    error "libiced_hs.a does not exist"
  Hooks.addRuleMonitors [Hooks.monitorFile "libiced_hs_.a"]
  Hooks.registerRule_ "iced:library-archive" $ 
    Hooks.staticRule 
      command
      [FileDependency icedLibrary]
      (NE.singleton destinationLocation)

Pull Request.

Unfortunately, I’m getting an error message that mentions autogen, whereas I’m not really pre-processing modules or generating modules, but just moving things around:

Warning: The following rules are not demanded and will not be run:
- RuleId {ruleNameSpace = RulesNameSpace {rulesUnitId = UnitId "main",
rulesModuleName = ModuleName "SetupHooks", rulesSrcLoc = (26,60)}, ruleName =
"iced:library-archive"},
generating [dist-newstyle/build/x86_64-linux/ghc-9.6.6/iced-hs-0.0.3.0/build
</> libCiced.a]
Possible reasons for this error:
- Some autogenerated modules were not declared
(in the package description or in the pre-configure hooks)
- The output location for an autogenerated module is incorrect,
(e.g. the file extension is incorrect, or
it is not in the appropriate 'autogenComponentModules' directory)

Am I abusing hooks by using them in this way? Should I fall back to a Custom setup instead?

1 Like