This is what I do currently, although I'm not sure if this won't cause
troubles.
As of ghc-mod: as far as I understand (didn't dig into this much, just read
in hdevtools documentation), hdevtools is just ghc-mod with client-server
architecture, so that it supports incremental recompiles (and thus faster
for subsequent invocations). If this is so, I do not see reason to continue
supporting ghc-mod.
On Fri, Feb 21, 2014 at 4:09 PM, AlanKim Zimmerman
In terms of using the right section of cabal, in the dev/editor environment you actually need to union of all the cabal targets, so all the various hs-src directories etc are in scope.
Alan
On Fri, Feb 21, 2014 at 2:05 PM, Daniel Trstenjak < daniel.trstenjak@gmail.com> wrote:
Hi Maxim,
I was aware of this hackish vim-script. I even tried to use that but fell into lots of corner cases and dropped. It does not handle inter-package dependencies, haskell language extensions, different code or sandbox layout.
It's definitively nice to reuse the information of the cabal file, I just don't like the coupling of tools that much.
Also there seems to be duplicate effort for supporting cabal sandboxes in ghc-mod and hdevtools.
It would be nice to have a tool that extracts the ghc relevant options from the cabal file which then could be used by ghc-mod, hdevtools or any other tool that wants to use ghc in conjunction with cabal.
Getting the ghc options right you also have to use the right cabal section (which executable, library, which test suite ...), so a seperate tool could nicely support this.
Greetings, Daniel _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe