Prefer package.yaml ghc-options over stack.yaml ghc-options

[Benjamin-McRae-Tracsis]

Please correct me if I'm wrong, but I believe that if you have ghc-options in a package.yaml for a package, and ghc-options in stack.yaml for the entire project, when you build the project the package's flags are placed first, and then the project's are placed.

This results in the following irritating behaviour:

• -Wall is enabled in stack.yaml
• in package.yaml, we choose to ignore a warning for whatever reason
• when we build, the warning is not ignored, because -Wall comes after the -Wno- in package.yaml

The expected behaviour would be that the warning is suppressed within that package.

My preference for ordering how options are applied in a given module is as follows:

1. global config.yaml
2. project-wide stack.yaml
3. package.yaml
4. command line options
5. options applied within the module

Please let me know if this has already been shot down or discussed elsewhere.

[mpilgrem]

@Benjamin-McRae-Tracsis, I'll have a look in Stack's code. In the light of your question, Stack's online help - https://docs.haskellstack.org/en/stable/yaml_configuration/#ghc-options and https://docs.haskellstack.org/en/stable/build_command/#-ghc-options-option - is not as clear as it could be.

[mpilgrem]

@Benjamin-McRae-Tracsis, I think the answer is this: --ghc-options passed to Cabal (the library) override those in a Cabal file for a package (including one created from a package.yaml file by Stack). --ghc-options passed from Stack to Cabal (the library) have this order (with later ones prevailing over earlier ones): from_config.yaml from_stack.yaml from_command_line.

As the Cabal mechanism is one of overriding what the package description requires, I think what you need for your specific -Wall example is (although that does not address your desire to disable the overriding mechanism for a specific package):

ghc-options:
  "$everything": -Wall
  my-exceptional-package: -Wno-all <warnings actually wanted for that package>

A disabling mechanism would need a new Stack configuration option - say, ignore-ghc-options. However, given the maturity of Stack's --ghc-options mechanism, I would personally like to hear from more users before implementing it.

[Benjamin-McRae-Tracsis]

Thanks for the quick reply. It seems that this order makes a level of sense; the package.yaml flags are overruled by the stack.yaml flags because they're kind of unrelated systems for making flags, and the stack.yaml ones are meant to overrule whatever an individual package says.

I read through your documentation changes, and I feel like it would be worth outlining this somewhere; that is, that the project-wide options overrule individual ones.

Instead of your suggested change in the stack.yaml of changing the flags for each package there, I think what I'll do in this case is use hpack directives to make sure every package has -Wall, and then I can do the ghc-options scoping correctly.

[mpilgrem]

I've added a little more to the documentation in the light of your comments.