Closed spacekitteh closed 11 months ago
It looks like haskell.nix fails running Setup register
during the install phase. Adding -v
reveals that Setup register
runs ghc
like this:
Running: /private/tmp/nix-build-cosmic-modelling-lib-cosmic-modelling-0.1.0.0.drv-2/tmp.5BCLy7xIAC/bin/ghc --abi-hash -fbuilding-cabal-package -O -outputdir dist/build -odir dist/build -hidir dist/build -stubdir dist/build -i -idist/build -ilib -idist/build/autogen -idist/build/global-autogen -Idist/build/autogen -Idist/build/global-autogen -Idist/build -optP-include -optPdist/build/autogen/cabal_macros.h -this-unit-id cosmic-modelling-0.1.0.0-Ewe4Gw6q8eX2a5MsGTb26h -hide-all-packages -Wmissing-home-modules -no-user-package-db -XGHC2021 -XGADTs -XTemplateHaskell -XLambdaCase -XDeriveGeneric -XDeriveAnyClass -XLinearTypes -XFlexibleContexts -XBlockArguments -XRecordWildCards -XScopedTypeVariables -XDataKinds -XKindSignatures -XDerivingStrategies -XDerivingVia -XStandaloneDeriving -XMultiParamTypeClasses -XTypeApplications -XRankNTypes -XPolyKinds -XAllowAmbiguousTypes -XTypeFamilies -XFlexibleInstances -XFunctionalDependencies -XApplicativeDo -XNoFieldSelectors -XTypeOperators -XOverloadedStrings -XConstraintKinds -XDeriveDataTypeable -XUndecidableInstances -XDeriveFunctor -XDeriveFoldable -XDeriveTraversable -XMultiWayIf -XViewPatterns -XOverloadedLabels -XQualifiedDo -XRoleAnnotations -XTupleSections -XQuantifiedConstraints -XBangPatterns -XUnliftedDatatypes -XDeriveLift -XQuasiQuotes Development.DomainModelling -Wall '-fplugin=Polysemy.Plugin'
The Setup register
is passing -hide-all-packages
and so even though the ghc-pkg list
does include the polysemy-plugin
package, it is hidden.
I'm not sure if we can fix this in haskell.nix or if it needs to be addressed in Cabal
. I did find two workarounds:
Add -package
to the ghc-options
in the .cabal
file to unhide the package during Setup register
:
ghc-options: -package polysemy-plugin-0.4.5.1 -fplugin=Polysemy.Plugin
Use a pragma in the .hs
files instead of setting ghc-options
:
{-# OPTIONS_GHC -fplugin=Polysemy.Plugin #-}
Hmm. Both of those workarounds are incredibly unappealing, but the former can probably be automated by haskell.nix
, no?
Unfortunately haskell.nix does not interact with the ghc-options
in the .cabal
file. It just runs Setup configure
, Setup build
, Setup copy
and Setup register
in the directory containing the .cabal
file. The Cabal
code in Setup
knows about and uses the ghc-options
field.
It is interesting that cabal build
is working. I wonder if it runs Setup register
. Perhaps cabal build
is respecting the cabal-version: 3.4
and using Cabal
3.4
to build a Setup
exe to use. Haskell.nix uses the latest Cabal
version (3.10
IIRC) for default Setup
(used for built-type: Simple
).
I'm pretty sure cabal-version: 3.4
just indicates the version of the file format though.
It specifies a minimum version :)
Also, I just remembered; this used to work. I had my CI set up such that it would run various flake outputs. Now it doesn't.
It looks like the behaviour of ghc
has changed (not Cabal
). When running ghc --abi-hash
any plugin modules passed on the command line must now be present in the package database. This was not the case will older versions of ghc.
This is easy to verify with:
$ ghc-9.4.7 --abi-hash -fplugin=Foo
921dcb31e865da25523dc30d4957f9c4
$ ghc-9.6.3 --abi-hash -fplugin=Foo
<command line>: Could not find module ‘Foo’
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
@hsyl20 does ghc --abi-hash
need to find the plugin modules to work correctly? If so does that mean Cabal
register
should be passing the configured module database arguments to ghc --abi-hash
(the same way I presume Cabal
build
passes them to ghc --make
)?
@hamishmack It looks like it's the effect of https://gitlab.haskell.org/ghc/ghc/-/commit/18a7d03d46706d2217235d26a72e6f1e82c62192#519f43ef6302b87fec67179ff5343fb9706e9748_261_266 Indeed plugins are loaded much earlier than before to be able to install hooks earlier.
If it breaks cabal register
please open a Cabal ticket. I'm not sure it counts as a regression on the GHC side as nothing is really specified anyway...
@andreabedini You might be interested in this
I opened https://github.com/haskell/cabal/pull/9384, let's see what the CI says.
Is it possible this fix does not work for GHC 9.8? I'm seeing a build failure similar to the one described, and I'm using a much more recent version of haskell.nix (#0dafd67f2e18e76d413cb2fbd0c01d0d028583f3)
While trying to build any of my libraries (or any packages which depend on those libraries) which use GHC plugins, I get the following error:
I obviously have it in the
build-depends
in the cabal file. The .cabal file looks like this:If I enter a shell with
nix develop
, and thencabal build
, it compiles just fine.Haskell.nix version: 66191dfde73ab8c1344c40b1163fdd04d161fefc GHC version(s): 9.6.2, 9.6.3 NixOS, x86_64-linux