Add support for cabal custom-setup

[mgsloan]

Currently we have explicit-setup-deps as a hack to say "Use the package's deps to build Setup.hs". It'd be much more principled to use the new custom-setup / setup-depends stuff.

• Update library dep to Cabal 1.24
• Figure out how it works. Are there docs? Hopefully it's just a component stanza..
• Re-use the same logic used for generating ghc arguments for stack ghci

Split off from #2093 (comment)

[rcook]

+1: The various gtk2hs projects (https://github.com/gtk2hs/gtk2hs) make extensive use of Setup.hs along with custom-setup and setup-depends and are quite tricky to build with Stack as a consequence.

[mgsloan]

Hmm, so now gtk3 can only be built with the very latest cabal?!

The cabal file could be modified to work with explicit-setup-deps. The library deps just need to be a superset of the Setup.hs deps. So in https://github.com/gtk2hs/gtk2hs/blob/master/gtk/gtk3.cabal, gtk2hs-buildtools needs to be a dep of the library. I can't think of many reasonable cases where this solution could be applied.

So basically, right now cabal has its way of addressing this (which we should probably add support for), and stack has its way of addressing this. Gtk2hs currently does not define things such that we can make them work via explicit-setup-deps.

[rcook]

Yes. I already used this workaround here: https://github.com/rcook/gtk-mac-integration/tree/p-rcook-stackify-1. It works for now!

[hvr]

fwiw, the semantically wrong hack of adding gtk2hs-buildtools to build-depends won't work anymore with future cabals, as build-depends only requests lib: components, but no exe: components.

[garetxe]

I am running into this issue with the gobject-introspection based bindings for gtk: https://hackage.haskell.org/package/gi-gtk .

The bindings are generated at cabal configure time using the haskell-gi dependency. In order to make this work with cabal new-build one needs to specify the haskell-gi dependency in custom-setup and set the cabal-version field to >= 1.24.

But then stack build rejects this, with

setup: This package description follows version 1.24 of the Cabal
specification. This tool only supports up to version 1.22.8.0.

So as far as I have been able to tell so far, the current situation is that I am forced to choose between supporting stack and supporting cabal new-build.

My problem could be worked around by stack accepting newer versions of the cabal spec, without really supporting them, but better would be to actually support the custom-setup syntax.

[rcook]

@garetxe: You can upgrade the version of Cabal used by Stack using stack setup --upgrade-cabal. This will upgrade to Cabal-1.24.0.0: this is how I was able to get gtk-mac-integration building (https://github.com/rcook/gtk-mac-integration/blob/p-rcook-stackify-1/gtk3-mac-integration.cabal).

[hamishmack]

I have prepared an update to Gtk2Hs that I hope will address the concerns @hvr raised. It will still use custom-setup, but everything will be in the library component of gtk2hs-buildtools.

[garetxe]

@rcook Thanks for the suggestion. But my issue is how to distribute the package reliably to end-users, not so much how to build it myself. Unless I misunderstand, I would have to ask every user of the library to run stack setup --upgrade-cabal before being able to use the libraries in stackage, which is far from ideal.

Anyway, so far I could not figure out how to make all of stack build, cabal build and cabal new-build work simultaneously, so I worked around this by making the stackage version have the explicit-setup-deps workaround, and releasing a newer version in hackage that does not have the workaround, and rather uses the new custom-setup syntax.

[garetxe]

Ah, I just saw that stackage nightly moved to cabal 1.24. So maybe now it is possible to support all options.