Ok, so this email concerns two main thing I wanted to run by people before I 
invest the effort. So in my "avoid recompilation sage" [1] I've run into an 
issue where reducing local recompilation ends up throwing away flags intended 
for ghci when running "cabal new-repl". Stemming from a mix of throwing away 
flags that don't affect build output and the fact that the only way to pass 
options to ghci at the moment is via "--ghc-option". (See the last 2 comments 
in the PR for details).

So the solution proposed in the PR was to add a separate "--ghci-option", which 
leads two issues:

1) All current new-X command have a "CommandUI" that basically mimics the 
original "install" command in what it returns (i.e. "CommandUI (ConfigFlags, 
ConfigExFlags, InstallFlags, HaddockFlags)"). Is there a specific reason 
they're all the same, or is it just a matter of "we haven't had a need to 
expand any of them yet?". In other words, can I simply extend "replCommand" to 
take extra flags returned in their own data structure?

2) Secondly, in the PR I proposed "--ghci-option", but that'd honestly result 
in rather tricky overlap with configured programs, possible undoing part of the 
work to avoid building configurations, etc. It's also highly GHC specific. I 
was wondering whether it wouldn't be better to simply add a "--repl-option" 
instead which just forwards it's arguments to whatever REPL command that 
happens to get invoked. The added bonus of this approach is that it'd be fairly 
trivial to apply the same approach to old "repl" so that it works with Setup.hs 
too (if that's desired).

Cheers,
Merijn

[1] - https://github.com/haskell/cabal/pull/5287

Attachment: signature.asc
Description: Message signed with OpenPGP

_______________________________________________
cabal-devel mailing list
cabal-devel@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

Reply via email to