Provide way to retrieve current GHC path in a code generator #10632
Labels
re: code-generators
Concerning the `code-generators` field/functionality for `testsuite`s
type: enhancement
Comments
RyanGlScott
added
type: enhancement
re: code-generators
RyanGlScott
referenced
this issue
in goldfirere/singletons
Dec 10, 2024
This replaces `singletons-base`'s custom `Setup.hs` script with a `cabal` code generator. This finally allows `singletons-base` to have a `Simple` build type, but at the (relatively less extreme) cost of requiring `Cabal-3.8` or later in order to build. Remarkably, everything that the custom `Setup.hs` script did can be done in a much simpler way with a `cabal` code generator, as all of the information that the `singletons-base` test suite needs to invoke GHC can be inferred from the arguments passed to a code generator. One downside is that due to haskell/cabal#8421, the code generator must be implemented in a standalone executable package (`singletons-base-code-generator`). Until that `cabal` issue is fixed, we will need to upload `singletons-base-code-generator` to Hackage with each `singletons` release. Fixes #532.
|
cc @gbaz |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the feature request
Currently, there does not appear to be a way to retrieve the path of the current GHC version you are using to build a package in the context of a
cabalcode generator. As such, in order to programmatically retrieve the GHC path, one has to resort to tricks like what theghc-pathslibrary does. This is unsatisfying for multiple reasons:ghc-pathsrequires a customSetup.hsscript. One of the key use cases forcabalcode generators is to avoid customSetup.hsscripts, so needing to depend on a package which uses a customSetup.hsscript in order to use a code generator is unfortunate.ghc-paths's assumptions about where GHC is installed are incorrect if you relocate your GHC installation.Additional context
I encountered this in the context of goldfirere/singletons#622, in which I replaced
singletons-base's customSetup.hsscript with a code generator. While usingghc-pathsas part of this solution mostly works, I am missing the ability to completely remove the dependency on customSetup.hsscripts due to the need for aghc-pathsdependency. (This dependency is only used in thesingletons-basetest suite, however, so the situation is not as severe as when the entiresingletons-baselibrary required a customSetup.hsscript.)The text was updated successfully, but these errors were encountered: