cabal repl, .ghci vs .cabal options

[ivan-m]

I have a ~/.ghci with some options specified, such as :set -Wall.

In a recent project, I wanted to disable a particular warning, so I'll specify in the *.cabal file:

ghc-options: -Wall -Wno-unused-top-binds

However, if I then do a cabal repl, I still get those warnings. Shouldn't the local *.cabal options override the global .ghci ones?

[hvr]

I'm not sure we can do much here. Cabal just passes ghc-options as instructed to GHCi; but then GHCi reads the .ghci file on startup. We could pass -ignore-dot-ghci, is that what you're suggesting?

(btw, I way to workaround this is that should work is to use per-file {-# OPTIONS-GHC -Wno... #-})

[ivan-m]

Preferably ghci would read .ghci first before the .cabal options are passed through. Though I gather this might not be possible.

[ivan-m]

And I usually do specify options on a per file basis, but in this case I was trying to avoid CPP.

[hvr]

It could be possible, but for that we'd have to extend/change GHC to allow to control the point at which .ghci is evaluated relative to CLI flag handling. I just have no idea how much work it would be, and if it would be justifiable.

[ivan-m]

I thought that might be the case, but thought it was worth asking :)

[ulysses4ever]

From the discussion above, I gather that OP finds confusing the order of argument processing in ghci. I can sympathize but I doubt we could do much about it, or whether it's even desirable to change the current behavior. Hence, I propose we close. If someone wants to champion the idea to pass --ignore-dot-ghci by default, they are free to open a fresh ticket.

[Mikolaj]

Indeed, by this time we have backward compatibility to contend with. But ideas are still welcome (with a conservative migration plan). Closing. Thank you everybody.