fltkhs icon indicating copy to clipboard operation
fltkhs copied to clipboard

Build error in Setup.hs

Open ericu opened this issue 4 years ago • 2 comments

I've just gotten back to my project after a break, during which I'd run "stack update" and pulled new FLTKHS code. I'm now getting this error when building my project. FLTKHS itself builds fine in isolation, so perhaps there's something new I need to do to accommodate your latest changes?

My stack.yaml has '../fltkhs' in its extra-deps and sets fltkhs: bundled to true. This all worked fine a couple of months ago, when I was still using your code from some time in November. I see that this error is in new code from February.

The error says you're giving arguments to a function that shouldn't take any; I see that it didn't receive any before 2551c0a2e4cca6099a5f8babb1a94262f998d27c, but I don't know that function. I also see https://www.haskell.org/cabal/release/cabal-latest/doc/API/Cabal/Distribution-Types-ComponentName.html showing it without any arguments and https://hackage.haskell.org/package/Cabal-3.2.0.0/docs/Distribution-PackageDescription.html#v:CLibName showing it with. Is there something wrong in how the version of cabal's libraries is specified, either in your code or in mine?

I'd appreciate any help.

uranium@Hex:~/projects/bcd3$ stack build
Cabal file warning in/home/uranium/projects/fltkhs/fltkhs.cabal@62:8: The field "build-tools" is deprecated in the Cabal specification version 2.0. Please use 'build-tool-depends' field
Cabal file warning in/home/uranium/projects/fltkhs/fltkhs.cabal@60:6: The field "build-tools" is deprecated in the Cabal specification version 2.0. Please use 'build-tool-depends' field
fltkhs> configure (lib + exe)
fltkhs> [1 of 2] Compiling Main             ( /home/uranium/projects/fltkhs/Setup.hs, /home/uranium/projects/fltkhs/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/setup/Main.o )
fltkhs>     
fltkhs> /home/uranium/projects/fltkhs/Setup.hs:397:39: error:
fltkhs>     • Couldn't match expected type ‘Maybe
fltkhs>                                       Distribution.Types.UnqualComponentName.UnqualComponentName
fltkhs>                                     -> ComponentName’
fltkhs>                   with actual type ‘ComponentName’
fltkhs>     • The function ‘CLibName’ is applied to one argument,
fltkhs>       but its type ‘ComponentName’ has none
fltkhs>       In the third argument of ‘componentNameTargets'’, namely
fltkhs>         ‘(CLibName (libName lib))’
fltkhs>       In the expression:
fltkhs>         componentNameTargets' pkg lbi (CLibName (libName lib))
fltkhs>     |
fltkhs> 397 |   case componentNameTargets' pkg lbi (CLibName (libName lib)) of
fltkhs>     |                                       ^^^^^^^^^^^^^^^^^^^^^^
            
--  While building package fltkhs-0.8.0.3 using:
      /home/uranium/.stack/programs/x86_64-linux/ghc-8.6.3/bin/ghc-8.6.3 --make -odir /home/uranium/projects/fltkhs/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/setup -hidir /home/uranium/projects/fltkhs/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/setup -i -i. -clear-package-db -global-package-db -package-db=/home/uranium/.stack/snapshots/x86_64-linux/798104e1d2e0e6cc65bcff22e51991486ed96ca3c463ff4aebfa84ba2f0c141e/8.6.3/pkgdb -package-db=/home/uranium/projects/bcd3/.stack-work/install/x86_64-linux/798104e1d2e0e6cc65bcff22e51991486ed96ca3c463ff4aebfa84ba2f0c141e/8.6.3/pkgdb -hide-all-packages -package-id=Cabal-2.4.1.0-Df4rkGuWEtO4aZs4eesJ3r -package-id=base-4.12.0.0 -package-id=directory-1.3.3.0 -package-id=filepath-1.4.2.1 -optP-include -optP/home/uranium/projects/fltkhs/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/setup/setup_macros.h /home/uranium/projects/fltkhs/Setup.hs /home/uranium/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs -main-is StackSetupShim.mainOverride -o /home/uranium/projects/fltkhs/.stack-work/dist/x86_64-linux/Cabal-2.4.0.1/setup/setup -threaded -fno-ignore-asserts
    Process exited with code: ExitFailure 1
Progress 1/2

ericu avatar May 30 '20 18:05 ericu

OK, it turned out that changing my project's resolver to lts-15.0 fixed my build. I don't know the build ecosystem well enough to know if this would be a deal-breaker for any dependent project, but it's probably at least worth a note in the docs somewhere.

ericu avatar May 31 '20 15:05 ericu

Thanks for letting me know. I'll add it to the docs.

deech avatar Jun 01 '20 19:06 deech