Inconsistent --ghc-options effect

[cblp]

--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]

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]

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

[cblp]

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]

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]

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]

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]

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]

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?