0

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?

imalison
  • 335
  • 3
  • 8
  • I think `stack build` uses cabal and your cabal file, which is unambiguous about which package provides the gtk bindings, whereas `stack exec -- ghc --make main.hs` uses all (with stack installed) packages which in your case includes both gtk versions. I cannot verify this right now, but i will check when I am at home – epsilonhalbe Oct 24 '17 at 20:25

1 Answers1

0

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

mgsloan
  • 3,245
  • 21
  • 20
  • The target option seems much better to me. So I take it you would be against changing the behavior of `stack ghc` to be consistent with that of stack ghci because you don't want to break backwards compatibility? – imalison Oct 26 '17 at 06:13
  • BTW - Just in case you are curious, the reason that I can't simply "The most straightforward way to do it is to make a cabal package which has the executable target." is that this compilation is taking place through the dyre package: https://github.com/willdonnelly/dyre . I suppose that things could be changed very significantly so that dyre tries to use stack more directly, but this was the quick and dirty fix that lives in the package ATM. – imalison Oct 26 '17 at 06:20
  • Yeah, `stack ghc` came before the code for `stack ghci` existed. I suppose if breaking changes are desired there it'd probably be better to do them earlier rather than later. – mgsloan Oct 26 '17 at 08:14