#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: [email protected] (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_______________________________________________
cabal-devel mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cabal-devel
