#382: 'cabal ghci' mode ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: Severity: major | Resolution: Keywords: | Difficulty: normal Ghcversion: 6.8.2 | Platform: ---------------------------------+------------------------------------------ Changes (by batterseapower): * cc: batterseapower+Cabal382@hotmail.com (added) Comment: I'm about to attach a patch I slapped together that implements this functionality. However, I just talked to Duncan and he says: {{{ dcoutts: BSP_: btw, if possible it'd be nice to export appropriate util functions from the GHC module and actually implement the feature in the cabal program (cabal-install package) [23:36] dcoutts: BSP_: eg we should be able to reuse a function for constructing ghc command lines [23:36] BSP_: it wasn't clear to me what the division of responsibility between cabal and cabal-install was [23:36] dcoutts: BSP_: here's how I see it now... [23:36] dcoutts: the program is for the user interface, it's a tool for devs [23:37] rfh_ left the chat room. [23:37] dcoutts: the lib is there to provide an implementation of the Cabal build system interface, which is currently specified as a command line interface [23:37] thetallguy1 left the chat room. (Read error: 104 (Connection reset by peer)) [23:38] BSP_: ok.. but the line is definitely blurred by the presence of stuff like CommandUI in the Cabal library itself [23:38] cognominal left the chat room. (Read error: 113 (No route to host)) [23:38] dcoutts: the lib has to implement a minimal cli so that package build scripts can call configure, build etc [23:39] dcoutts: BSP_: the crucial test I think is, does the rpm build script need it [23:40] dcoutts: I mean consider a random source rpm that has scripts for doing the build [23:40] BSP_: OK [23:40] dcoutts: it needs to configure, build, haddock, install [23:40] dcoutts: it's a machine api [23:40] dcoutts: where as cabal ghci blah is definitely aimed at end users, humans [23:41] BSP_: right [23:41] BSP_: btw i've called it "cabal interactive" instead, since theoretically you could implement the same thing for other compilers.. [23:42] dcoutts: BSP_: good, I do have qualms about it being too ghc specific [23:42] dcoutts: BSP_: and if people complain about the length of the command then we can remind them that we do provide command line completion! [23:42] BSP_: [23:43] dcoutts: currently only for bash, but others would be easy, the feature is built into cabal itself [23:44] thetallguy1 joined the chat room. [23:53] dcoutts: BSP_: if you're working on that area perhaps I can persuade you to do a little refactoring of the GHC module, particularly the way ghc command lines are constructed [23:54] BSP_: dcoutts: there is a lot of redundancy - but perhaps I should wait for your patches before changing it any further [23:54] dcoutts: Saizan and I started on an approach with a big GhcOptions record and a function renderGhcOptions :: GhcOptions -> [String] [23:55] dcoutts: the idea is that functions that generate or mess with options would use the nice structured GhcOptions values [23:55] dcoutts: I've got half an implementation of the idea I can send you [23:57] dcoutts: BSP_: pushing the changes now... [23:57] BSP_: dcoutts: cheers [00:00] dcoutts: BSP_: some early attempts here http://haskell.org/~duncan/cabal/GHC.hs [00:00] dcoutts: diff it vs the current ./Distribution/Simple/GHC.hs [00:00] pumpkin: oh wow, it's BSP on IRC! [00:01] dcoutts: BSP_: it's the commented out bit about GhcOptions [00:01] dcoutts: BSP_: so we'd make GhcOptions an instance of Monoid and functions like packageHsGhcOptions :: BuildInfo -> LocalBuildInfo -> GhcOptions [00:01] BSP_: pumpkin: hey there i think i recognise your name from github.. [00:02] pumpkin: yup! 'tis me [00:02] BSP_: dcoutts: right, i'll take a look - no promises though [00:02] dcoutts: BSP_: sure [00:02] dcoutts: BSP_: ideally it'd make it easy for you to do the ghci bits in an external module, in cabal-install [00:03] dcoutts: BSP_: ah, of course we'll have to branch cabal-install and have the new head branch use the head version of the Cabal library [00:04] dcoutts: the current stable cabal-install uses the released stable Cabal version [00:06] BSP_: ok }}} So in summary: * The GHC module needs a serious refactoring, perhaps using a GhcOptions monoid * The patch should be for cabal-install, not cabal * The second thing kind of depends on the first, so it makes sense to do these together I'll make these changes to the patch if I find the time, but if not at least the incomplete patch is here with the ticket. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/382#comment:9 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects