What could make this Setup.hs use case less heavyweight?

[gergoerdi]

I was asked on #haskell to report this use case of a custom Setup.hs because apparently the Cabal developers would like to minimize such cases. My personal opinion is that my use case is so ad-hoc that there isn't much to solve in general -- but I am not an expert in Cabal at all.

I have written extensively about my use case at https://unsafeperform.io/blog/2020-05-07-integrating_verilator_and_clash_via_cabal/. Basically, depending on the value of some custom x- fields in the various Cabal components, I need to run some Haskell code (Clash's defaultMain), in a context where all Cabal dependencies are already available, in order to generate an .hsc file and an .a static library. The hsc file is then compiled the standard way, and the .a file is linked statically into the resulting exe or library.

There are at least two parts of this process that aren't directly supported by Cabal:

• Generating multiple artifacts (a static library and an .hsc file) by one code generator / preprocessor
• Multi-phase code generator pipeline: my tool generates an .hsc file, which then needs to be further processed by hsc2hs to get the final .hs file suitable for consumption by GHC.

[sheaf]

There are at least two parts of this process that aren't directly supported by Cabal:

• Generating multiple artifacts (a static library and an .hsc file) by one code generator / preprocessor

• Multi-phase code generator pipeline: my tool generates an .hsc file, which then needs to be further processed by hsc2hs to get the final .hs file suitable for consumption by GHC.

You should be able to do this now with build-type: Hooks. Both of those limitations are lifted by the notion of pre-build rules provided by build-type: Hooks. In fact, this would be a very nice illustration of the feature.