Pass -optcxx for GHC >= 8.10

[ejconlon]

Intends to resolve this issue. To summarize, cabal passes all C and C++ flags through GHC to the underlying C or C++ compiler using -optc. This works for GHC < 8.10, but now GHC expects C++ flags to come through -optcxx. This means that anything through -optc is ignored, so we cannot pass any flags to the C++ compiler. This change simply detects the GHC version and uses the correct arguments.

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

This PR has been tested manually on this repro and two PackageTests have been added to cabal-testsuite. They pass under GHC 8.8.4 and GHC 8.10.2.

[phadej]

We need tests.

Also "negative" tests, that cxx-options are not passed to C-files, and C-options to C++-files as mentioned in a comment in the issue. (For GHC >=8.10).

[ejconlon]

Yep, let me see what I can do about tests. In the meantime, I verified that this fixes the issue as reproduced here with GHC 8.8.4 and 8.10.2.

[ejconlon]

@phadej would https://github.com/haskell/cabal/tree/master/cabal-testsuite/PackageTests be the right place to put test cases? I haven't found a suitable unit test suite for this, so I think the integration tests there are appropriate.

If so, I will put in two examples lifted from the repro, both configured with cc-options: -D__TESTOPT_C__ and cxx-options: -D__TESTOPT_CXX__:

1. A project including C sources that will #error if __TESTOPT_CXX__ is defined or __TESTOPT_C__ is NOT defined
2. A project including C++ sources doing the opposite

Is that comprehensive enough?

EDIT: seems like I need to split the c++ test case in two, one for new ghc asserting that we get cxx-options, and one for old ghc asserting that we get cc-options (to preserve current behavior)

[phadej]

@ejconlon yes, PackageTests is the place for such things. Having a full matrix of "old/new GHC, c-source/c++-source, flags" makes most sense to me, i.e. being systematic.

[ejconlon]

@phadej I put in two PackageTests: ForeignOptsC and ForeignOptsCxx. Assuming I ran them right, they both pass for me under both compilers with this change. Both of them pass cc-options and cxx-options and assert that they only pick up CPP flags from the correct one. If we are running them with 8.8 and 8.10 in the CI matrix, then I think we are in good shape.

[ejconlon]

(Also, if you're planning on doing another RC for 3.4 I would love to get this change picked in!)

[phadej]

Perfectly we would backport that to Cabal-3.2 (shipped with GHC-8.10), as far as I'm aware GHC-8.10.3 will definitely happen.

@bgamari should I prepare Cabal-3.2.1.0?

[phadej]

Squash commits, that will help backporting.

Write in the commit message what you have written in the description. Also write

Fixes https://github.com/haskell/cabal/issues/6421

(I prefer explicit URL, not an abbreviated number, as it makes easy to click from git log).

[ejconlon]

(By the way, this is the second commit for which that Windows job flaked out with some handle error!)

[bgamari]

Perfectly we would backport that to Cabal-3.2 (shipped with GHC-8.10), as far as I'm aware GHC-8.10.3 will definitely happen.

@bgamari should I prepare Cabal-3.2.1.0?

Yes, that would be great. Thank you!

[phadej]

@ejconlon yes, windows jobs are flaky. Don't worry.

[phadej]

Backported to 3.4 in #7074

[phadej]

Backported to 3.2 in #7134