Remove local options from global program options

[patrickdoc]

---

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog.
• The documentation has been updated, if necessary.

Please also shortly describe how you tested your change. Bonus points for added tests!

---

Local options for compiler related flags are 1) applied to all packages and 2) cached. Both of which seem incorrect.

This PR removes those options from the pre-configured program DB. Note that options are still applied correctly here:

cabal/cabal-install/src/Distribution/Client/ProjectPlanning.hs

Line 1914 in 7d66cea

<> perPkgOptionMapMappend pkgid packageConfigProgramArgs

There are lots of related issues around weird behavior trying to apply ghc-options:

• --ghc-options are cached, but shouldn't be #7816
• GHC incorrectly concludes rebuild unnecessary, even when ghc-options have changed #3891
• ghc-options applies to all dependencies, not just local packages #3883
• Package sections in cabal.project are insufficient, need local section #3579
• Explicitly support building with -fno-code #1176

This PR makes this cabal.project stanza work as intended, applying the ghc-options to all/only local packages:

program-options
    ghc-options: -Werror

and removes the need for this workaround:

package local-foo
  ghc-options: -Werror

package local-bar
  ghc-options: -Werror

[Mikolaj]

This is amazing! However, people have already got used to the wrong behaviour, so let's make sure we change it once and don't ask them to re-adjust repeatedly. Is the desired semantics completely clear or do we need to ask users, discuss again on the tickets you mentioned, etc.?

[jneira]

It is somewhat weird this did not break any test. I think we should add some sort of regression test to exercise the change and have evidences it fixes those issues

[jneira]

It is somewhat weird this did not break any test. I think we should add some sort of regression test to exercise the change and have evidences it fixes those issues

well, as noted in the pr description

This PR makes this cabal.project stanza work as intended, applying the ghc-options to all/only local packages

so it is not so weird there are no tests checking ghc-options are applied to non local packages

Probably this will break quite use cases, it is worth to note you can recover the old behaviour with

package *
  ghc-options: -Werror

if you have a local project. Not sure if there would be a easy one for installing from a tarball or hackage though

[patrickdoc]

Tests added to demonstrate old behavior/verify fix. Before the fix, tests failed with:

    program options local:    FAIL (1.93s)
      tests/IntegrationTests2.hs:1579:
      p
      expected: Nothing
       but got: Just ["-fno-full-laziness"]
      Use -p '/program options/&&/program options local/' to rerun this test only.

Here p is a tarball (remote) package which should not have local options applied to it. But, as the test demonstrates, local options are being applied to remote packages.

I need to double check, but I believe command-line options are also passed into the "local" portion of the project config, which means this would also affect that. I think command line only affecting local packages is the intended behavior, but as you mentioned it might break some use cases.

To recreate old behavior, this still works:

package *
    ghc-options: -Werror

[jneira]

great fix, thanks!

[Mikolaj]

Good job. Let me try to merge this.

[Mikolaj]

@Mergifyio rebase

[mergify]

rebase

☑️ Nothing to do

• -closed [:pushpin: rebase requirement]
• #commits-behind>0 [:pushpin: rebase requirement]