I have been trying build and run an application that needs access to the ghc package but I can't manage to expose it through stack.
I know this should be an easy flag -package ghc but how do I do that with stack?
I've tried this:
stack exec Engine-exe --package ghc-7.10.3 -- core
I get this:
Didn't see ghc-7.10.3 in your package indices.
Updating and trying again.
Fetching package index ...remote: Counting objects: 1, done.
remote: Total 1 (delta 0), reused 1 (delta 0), pack-reused 0
Unpacking objects: 100% (1/1), done.
Fetched package index.
The following package identifiers were not found in your indices: ghc-7.10.3
Perhaps you meant gc, ghci, ght, or lhc?
I've also tried to build it as: stack build --ghc-options -package ghc
and get the same result.
If your application needs to build against ghc, then add it to the build-depends in your cabal file. If your application needs to run the ghc executable, then it will be visible from within stack exec.
So if your project is using ghc-7.10.3, the proper ghc version should be on the PATH.
If you want stack exec to use a different resolver or compiler than configured, do stack --resolver lts-6.0, or stack exec --compiler ghc-7.10.3
I had forgotten about this!
For future reference.
In the end all I had to do was ghc-pkg expose ghc.
Related
I install GHC on Windows10 using the recommended Haskell Stack. I want to us GHC without all the Stack overhead for Advent of Code. This was working fine until I tried to get the extra package.
I can install it with Stack, but I don't seem to have a way to get it in the global package database. Haskell Stack apparently does not install the cabal executable and seems to have it locked out of their package database.
How do I install the extra package for use with vanilla GHC?
John Miller#DESKTOP-NENAGQH MSYS /d/dev/AdventOfCode2020
$ stack ghc -- AoC/Utils.hs
[1 of 1] Compiling AoC.Utils ( AoC\Utils.hs, AoC\Utils.o )
John Miller#DESKTOP-NENAGQH MSYS /d/dev/AdventOfCode2020
$ ghc AoC/Utils.hs
[1 of 1] Compiling AoC.Utils ( AoC\Utils.hs, AoC\Utils.o ) [Data.List.Extra changed]
AoC\Utils.hs:3:1: error:
Could not find module `Data.List.Extra'
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
|
3 | import Data.List.Extra
| ^^^^^^^^^^^^^^^^^^^^^^
I don't know whether stack supports installing to the global package DB. cabal does though:
$ cabal install --lib extra
Resolving dependencies...
Up to date
$ ghci
GHCi, version 8.10.2: https://www.haskell.org/ghc/ :? for help
Loaded package environment from /home/simon/.ghc/x86_64-linux-8.10.2/environments/default
Prelude> import Data.List.Extra
Prelude Data.List.Extra>
Ok, so stack can install the cabal executable if you beat at it long enough. The package is called cabal-install and it is not in any resolver, but is on Hackage.
stack install cabal-install
Because it is not in the resolver there is a pretty good chance that the version of Cabal, the library for manipulating cabal packages in Haskell, is not compatible. First, ask stack where it keeps its global config
stack path --config-location
Edit that file to allow for the needed dependencies under extra-deps: Stack will helpfully tell you what they are. It may also be helpful to change the resolver to a newer version in that file while your at it.
Now try
stack install cabal-install
again and if these instructions have not fallen out of date since December 2020 you will get the cabal executable somewhere potentially useful.
Before using cabal you will have to run a cabal update to get the package list.
At this point cabal should manipulate your global package database and stack can install GCH and all its libraries over and over and over again if you want to use it for a project instead. They should just keep out of each other's way.
For a new project, I have been trying to build the threepenny-gui package, something which I have done many times in the past without any trouble. This time however, I ran into an unusual error message:
> stack build
threepenny-gui > configure
threepenny-gui > Configuring threepenny-gui-0.9.0.0...
threepenny-gui > build
threepenny-gui > Preprocessing library for threepenny-gui-0.9.0.0..
threepenny-gui > Building library for threepenny-gui-0.9.0.0..
threepenny-gui > [ 1 of 29] Compiling Foreign.JavaScript.Include
threepenny-gui > [ 2 of 29] Compiling Foreign.JavaScript.Resources
threepenny-gui > ghc.exe: unable to load package `regex-posix-0.96.0.0'
threepenny-gui > ghc.exe: | C:\sr\snapshots\14724cfd\lib\x86_64-windows-ghc-8.8.4\regex-posix-0.96.0.0-11M5Q2Uki3ACYikP2WXOuq\HSregex-posix-0.96.0.0-11M5Q2Uki3ACYikP2WXOuq.o: unknown symbol `regerror'
-- While building package threepenny-gui-0.9.0.0 using:
C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_3.0.1.0_ghc-8.8.4.exe --builddir=.stack-work\dist\29cc6475 build --ghc-options " -fdiagnostics-color=always"
Process exited with code: ExitFailure 1
Progress 1/2
Now, a quick Google shows that this error message has been seen before — in 2010, after which it was fixed with a GHC update. I tried changing GHC versions (that output above was with GHC 8.8.4), but it didn’t work with 8.8.3 or 8.8.2 either. I also tried deleting regex-posix¹ and reinstalling it again, but that didn’t work either. At this point, I must confess that this error has completely stumped me; does anyone else have any idea what might be causing it, and if so, how can I fix it?
¹ Specifically, I removed C:\sr\snapshots\14724cfd\lib\x86_64-windows-ghc-8.8.4\regex-posix-0.96.0.0-11M5Q2Uki3ACYikP2WXOuq and C:\sr\snapshots\14724cfd\pkgdb\regex-posix-0.96.0.0-11M5Q2Uki3ACYikP2WXOuq.conf, and did ghc-pkg unregister regex-posix.
This turned out to be a problem in regex-posix rather than threepenny-gui. This issue could be fixed by enabling the Cabal flag _regex-posix-clib. To set it, I first needed to unregister the previous version of regex-posix:
> stack --resolver lts-16.23 exec -- ghc-pkg unregister regex-posix-0.96.0.0 --force
I then needed to rebuild it with the correct flag:
> stack build regex-posix-0.96.0.0 --flag regex-posix:_regex-posix-clib --resolver lts-16.23
After which stack build threepenny-gui --resolver lts-16.23 was successful. (For some reason, I needed to specify the resolver explicitly in these commands.)
A minimal reproduction can be found here:
https://github.com/IvanMalison/stack-gtk2hs-bug
Everything works as expected when I use normal stack commands, but when I run the failing command:
stack ghc -- --make main.hs
I get the following error:
main.hs:3:1: error:
Ambiguous interface for ‘Graphics.UI.Gtk’:
it was found in multiple packages: gtk-0.14.6 gtk3-0.14.6
main.hs:4:1: error:
Ambiguous interface for ‘Graphics.UI.Gtk.Abstract.Widget’:
it was found in multiple packages: gtk-0.14.6 gtk3-0.14.6
main.hs:5:1: error:
Ambiguous interface for ‘Graphics.UI.Gtk.Layout.Table’:
it was found in multiple packages: gtk-0.14.6 gtk3-0.14.6
The output of stack exec ghc-pkg -- --no-user-package-db list is https://gist.github.com/f19f900988f49e4d03cd61f1cab48baa . This output makes me expect that the reason that this is happening is that some other stack install required gtk (not gtk3 which is what is specified as a dependency in this package) and somehow this package is visible from the stack ghc command for some reason.
Am I misunderstanding the stack ghc command? Shouldn't this essentially do the same thing as stack build?
There's no builtin way to do this with stack currently. However, it is possible to get stack ghci to do this. The most straightforward way to do it is to make a cabal package which has the executable target. However, if you really want to just use straight ghc, there is a way. Copy-pasting from my comment here:
stack ghc works a bit differently than stack ghci. It's essentially a synonym for stack exec -- ghc, which will run the right compiler with the right databases, but won't set up anything related to your local packages like include directories etc. Note that stack ghci takes TARGET arguments whereas stack ghc does not. Retrospectively, this is a bit inconsistent, but stack ghc came before stack ghci.
It does make sense to have the ability to do something like this, though not sure how to best achieve that. Some potential options:
--no-interactive argument on stack ghci. Would be a bit obtuse. Weird to run a ghci command when, though it would be using the stack ghci logic.
Add --target TARGET option to stack ghc, to tell it to use the environment of a particular local package target.
Here's a workaround for now. Put the following in ~/.local/bin/stack-run-ghc.sh and make it user executable:
#/bin/sh
ghc $(echo "$*" | sed 's/--interactive//g')
This takes the arguments, removes --interactive, and calls ghc. With this, I can build stack using ghc via the following:
stack ghci --with-ghc stack-run-ghc.sh --ghci-options src/main/Main.hs
I depend on a package that needs alex to build, i also need ghcjs.
When i try to run stack ghci:
language-java-0.2.8: configure (lib)
Error:
-- While building package language-java-0.2.8 using:
<long command>
Process exited with code: ExitFailure 1
Logs have been written to: /Users/LeanderK/Documents/Haskell/exemplator-java_parser/.stack-work/logs/language-java-0.2.8.log
Configuring language-java-0.2.8...
Cabal-simple_mPHDZzAJ_1.24.2.0_ghcjs-0.2.1.9007019_ghc-8.0.1: The program
'alex' version >=3.1.3 is required but it could not be found.
Warning: Build failed, but optimistically launching GHCi anyway
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
Configuring GHCi with the following packages: exemplator-client
Using main module: 1. Package `exemplator-client' component exe:exemplator-client-exe with main-is file: ..../app/Main.hs
Progress: 1/2<command line>: cannot satisfy -package language-java-0.2.8
(use -v for more information)
I've tried: stack build alex (just returns, don't have any output. Might work), stack install alex (doesn't work).
Output of stack install alex
Couldn't find executable alex in directory .../.stack/snapshots/x86_64-osx/lts-7.19/ghcjs-0.2.1.9007019_ghc-8.0.1/bin/
For reference: This is the cabal file of the dependency, unfortunately only found on github. This is my stack and my cabal file. There is also a reddit discussion that didn't go anywhere.
When building threepenny-gui on NixOS with stack --nix build, I got error saying I have the wrong version of ghc. Then I tried stack --nix setup, which doesn't run because bash is on an unexpected path on NixOS (that's expected, since the stack documentation only mentions stack --nix build not setup). What am I missing?
FYI, to deal with the zlib issues I have also added a shell.nix and default.nix per https://github.com/commercialhaskell/stack/issues/2130
EDIT: was able to build with the method suggested by mkkeankylej from the above link, i.e. editing ~/.stack/config.yaml and add zlib to buildInputs in shell.nix But I'd still like to know if there's a way to do it w/o falling back to nix-shell? It sounds like stack --nix build should work as long as the nix-shell method does.
First of all, threepenny-gui seems to provide no stack.yaml, i.e. the project isn't configured to be built with stack. Thus, I wonder why you even bother using stack since that is not going to be any easier than building the project with cabal-install or even Nix directly. The easiest and fastest way is probably to configure the build by running:
$ nix-shell "<nixpkgs>" -A haskellPackages.threepenny-gui.env --run "cabal configure"
Afterwards, you can simply "cabal build" the project and work with it (inside or outside of a nix-shell) as you please; the compiler and all necessary build dependencies are provided by Nix.
If you don't want that, then you can use the normal cabal-install approach:
$ cabal sandbox init
$ cabal install --only-dependencies
$ cabal configure
$ cabal build
That build is probably going to require system libraries, like libz, so you must make sure that those are available. There's a million different ways to accomplish that, but the cleanest IMHO is the following:
$ zlibinc=$(nix-build --no-out-link "<nixpkgs>" -A zlib.dev)
$ zliblib=$(nix-build --no-out-link "<nixpkgs>" -A zlib.out)
$ cabal install --only-dependencies --extra-include-dirs=$zlibinc --extra-lib-dirs=$zliblib
Last but not least, it's not obvious to me why your stack build --nix command won't succeed, because that command will use Nix to install the proper version of GHC automatically. So if that doesn't work, then my best guess is that you're using an old version of stack where that feature doesn't work properly. I've tried that build using the stack binary that Nix provides, stack 1.3.2, and it can compile a current git checkout of threepenny-gui just fine:
$ git clone git://github.com/HeinrichApfelmus/threepenny-gui.git
Cloning into 'threepenny-gui'...
remote: Counting objects: 4102, done.
remote: Total 4102 (delta 0), reused 0 (delta 0), pack-reused 4101
Receiving objects: 100% (4102/4102), 1.88 MiB | 581.00 KiB/s, done.
Resolving deltas: 100% (2290/2290), done.
$ cd threepenny-gui
$ stack init
Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- threepenny-gui.cabal
Selecting the best among 9 snapshots...
* Partially matches lts-7.16
websockets-snap not found
- threepenny-gui requires >=0.8 && <0.11
Using package flags:
- threepenny-gui: buildexamples = False, network-uri = True, rebug = False
* Matches nightly-2017-01-17
Selected resolver: nightly-2017-01-17
Initialising configuration using resolver: nightly-2017-01-17
Total number of user packages considered: 1
Writing configuration to file: stack.yaml
All done.
$ stack build --nix --nix-packages zlib
threepenny-gui-0.7.1.0: configure (lib)
Configuring threepenny-gui-0.7.1.0...
threepenny-gui-0.7.1.0: build (lib)
Preprocessing library threepenny-gui-0.7.1.0...
[...]
Registering threepenny-gui-0.7.1.0...
This works without any specially edited config files for nix-shell, nor does it require special customization of stack.