CODEWITHSUNDEEP
haskellgtkgtk3haskell-stackgtk2hs
imalison
imalison

Reputation: 365

Both versions of the gtk package are visible when running `stack ghc`

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?

Upvotes: 0

Views: 181

Answers (1)

mgsloan
mgsloan

Reputation: 3295

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

Upvotes: 0

Related Questions