Add support for building profiled dynamic way

[mpickering]

Add support for profiled dynamic way

New options for cabal.project and ./Setup interface:

* `profiling-shared`: Enable building profiling dynamic way
* Passing `--enable-profiling` and `--enable-executable-dynamic` builds
  profiled dynamic executables.

Support for using `profiling-shared` is guarded behind a constraint
which ensures you are using `Cabal >= 3.13`.

In the cabal file:

* `ghc-prof-shared-options`, for passing options when building in
  profiling dynamic way

Other miscellenious fixes and improvements

* Some refactoring around ways so that which
  ways we should build for a library, foreign library and executable is
  computed by the `buildWays` function (rather than ad-hoc in three
  different places).

* Improved logic for detecting whether a compiler supports compiling
  a specific way. See functions `profilingVanillaSupported`,
  `dynamicSupported`, `profilingDynamicSupported` etc
  These functions report accurate infomation after ghc-9.10.1.

* Fixed logic for determining whether to build shared libraries. (see
  #10050)
  Now, if you explicitly enable `--*-shared`, then that will always take
  effect. If it's not specified then `--enable-executable-dynamic` will
  turn on shared libraries IF `--enable-profiling` is not enabled.

* Remove assumption that dynamically linked compilers can build dynamic
  libraries (they might be cross compilers.

* Query the build compiler to determine which library way is necessary
  to be built for TH support to work.
  (rather than assume all compilers are dynamically linked)

* An extensive test which checks how options for `./Setup` and
  `cabal-install` are translated into build ways.

Fixes #4816, #10049, #10050

[mpickering]

I require the version to be bumped to 3.13 before this can be finished.

[ulysses4ever]

That's

• Bump project version from 3.11 to 3.13 #9897

[mpickering]

The test fails on 8.6.5 because of this GHC bug (fixed in 2018): e400b9babdcf11669f963aeec20078fe7ccfca0d

[mpickering]

Can someone please review this patch? I would like to get it off my plate as I have been working on it for quite a while.

[geekosaur]

No additions beyond what @sheaf said.

[mpickering]

I made two recent improvements.

• Better handling of -dynamic-too
• Enforce that Cabal >3.13 constraint applies to all setups if profiling dynamic is used anywhere (this is conservative).

[andreabedini]

The two new fields ghc-prof-shared-options and ghcjs-prof-shared-options need to be guarded behind the new cabalSpecVersion.

I feel the code to handle "way" keeps getting more and more complex. Is there any way we can reduce this complexity?

E.g. do we really need to know what GHC support in what situation? can we instead just do what the user wants and leave GHC to deal with it? Otherwise we end up replicating a bunch of logic that belongs to the compiler.

[mpickering]

I feel the code to handle "way" keeps getting more and more complex. Is there any way we can reduce this complexity?

E.g. do we really need to know what GHC support in what situation? can we instead just do what the user wants and leave GHC to deal with it? Otherwise we end up replicating a bunch of logic that belongs to the compiler.

Is there a particular bit of code which you find too complicated? I have just extended how cabal-install has already worked in relation to ways (and actually simplified a lot of the calculations about which ways are built and needed).

I have fixed the issue now about the cabal spec version, that is a good point.

[Mikolaj]

@andreabedini: was your concern answered satisfactorily? If so, could you mark it in the system so that mergify knows to proceed? Thank you!

[andreabedini]

@Mikolaj My comment about the complexity was not essential to the request for changes. My only request was to guard the fields behind cabalSpecVersion, which has been acted upon. Thanks @mpickering.