Bikeshedding (new-)repl's commandline UI
merijn at inconsistent.nl
Tue May 8 11:02:56 UTC 2018
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"  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).
 - https://github.com/haskell/cabal/pull/5287
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 874 bytes
Desc: Message signed with OpenPGP
More information about the cabal-devel