On 18 October 2014 22:36, Herbert Valerio Riedel
ordinary Cabal package (so it doesn't require to setup a GHC source-tree and wrangle with the GHC build-system), if you're lucky enough (which is most of the time) that the parts you want to tweak don't require changing the GHC API.
Right, so far my work on ghc-server has all been doable as far back as GHC 7.2. Iirc all of the deltas in ghci-ng-7.6 relative to GHC 7.6.3 landed in
GHC 7.8.1, so extracting the latest GHCi frontend code would be probably better.
Okies! Supporting multiple major-versions of the GHC API simultanously in the
same code-base could prove to be rather tedious (and make it more
difficult to extract clean patches to merge back into GHC HEAD). But this is only speculation on my part, so your mileage may vary....
It hasn’t been too tedious to support old versions at least on ghc-server — I went back as far as 7.2, but GHC 7.6 for example is very similar to 7.8 so kind of comes “for free”. Makes sense, really. One major version bump to another is rather passable, it’s when going a few versions back that it becomes tedious. At least in my experience. I’ll see anyway. You may want to be careful with the build-deps though; e.g. if you use
JSON and want this to be merged back into GHC HEAD at some point, we may need something lighter than the usual go-to JSON implementation `aeson` in terms of build-deps...
Indeed, I was considering extracting and embedding a simple parser/printer from the old json package (remember that?). Served me well for years before aeson usurped it. :-) I think it can be reduced down to one module that operators on Strings. PS: I've added you to
http://hackage.haskell.org/package/ghci-ng/maintainers/, just in case...
Thanks!