search

commercialhaskell / stack

The Haskell Tool Stack
http://haskellstack.org
BSD 3-Clause "New" or "Revised" License
3.98k stars 842 forks source link

Inconsistent --ghc-options effect #3485

Open cblp opened 6 years ago

cblp commented 6 years ago

--ghc-options overrides ghc-options in component configuration but doesn't override OPTIONS_GHC in the module.

When I want to test my package, I run stack test --pedantic. When I want to disable some warnings for a single module, I put OPTIONS_GHC in it. When I want to disable some warnings for a single component, I can't do this! Component configuration can't override command-line options!

$ stack --version
Version 1.5.1, Git revision 600c1f01435a10d127938709556c1682ecfd694e (4861 commits) x86_64 hpack-0.17.1
mgsloan commented 6 years ago

Hmm, interesting. So the issue is that .cabal components cannot override --ghc-options / --pedantic? Seems expected to me.

I think the issue here is that pedantic implies -Wall. This is convenient, but messes with circumstances like this. I don't think we can put -Wall before the component's options, because that part is done by the Cabal library.

I suggest adding a pedantic flag to your package, and using that instead of --pedantic.

cblp commented 6 years ago

If you expect that component can't override command-line options, then you must expect that module can't override command-line, too.

cblp commented 6 years ago

pedantic implies -Wall

Yes, it's obvious, and the problem starts after that.

The issue is that I can't develop expectations about meaning of stack's command-line options.

mgsloan commented 6 years ago

If you expect that component can't override command-line options, then you must expect that module can't override command-line, too.

Uhh, that's a detail of ghc. I believe that OPTIONS_GHC always overrides command line options. Are you using -fno-warn-? Perhaps you are expecting enabling warnings in OPTIONS_GHC will reset which warnings are used? This is not how it is done typically. Instead, you should enable the superset of all warnings you want, and then disable them selectively in modules.

The issue is that I can't develop expectations about meaning of stack's command-line options.

Not sure what this means? These options are just passed to Cabal. We can't really do anything different here. Cabal adds them to the end, after the component options. This is sensible behavior.

cblp commented 6 years ago

Hm, I will try to answer these questions one more time, in other words.

I run stack build --ghc-options=-Wall and expect everything is compiled with options -Wall. OK.

I run stack build --ghc-options=-Wall with -Wno-orphans added to a module and expect this specific module will be compiled with -Wall -Wno-orphans. OK.

I run stack build --ghc-options=-Wall with -Wno-orphans added to a component and expect this specific component will be compiled with -Wall -Wno-orphans. FAIL?

mgsloan commented 6 years ago

Quoting myself from above:

These options are just passed to Cabal. We can't really do anything different here. Cabal adds them to the end, after the component options.

AFAIK the only way we can solve that is by changing cabal's behavior. These are just being passed into cabal, and it is making the choice to append the cli options after the component options. Is this ideal and consistent? You're right, it's not. Please open an issue on https://github.com/haskell/cabal about it.

mgsloan commented 6 years ago

Re-opening so that when this is revisited down the road, maybe there will be a way to do this with future versions of cabal.

cblp commented 6 years ago

stack-1.2 seems to work properly (per-component options are put after stack-command-line options).

What is the best way to test this against different versions of the stack?