|
| 1 | +## Cabal and Cabal-syntax 3.14.0.0 & 3.14.1.0 changelog |
| 2 | + |
| 3 | +For reasons of discoverability, the changelog of Cabal & Cabal-syntax 3.14.0.0 is also included in this file, since that version had been released for the benefit of GHC 9.12's release process. |
| 4 | + |
| 5 | +### Significant changes |
| 6 | + |
| 7 | +- Fix build ways for modules in executables [#10418](https://github.com/haskell/cabal/issues/10418) [#10419](https://github.com/haskell/cabal/pull/10419) |
| 8 | + |
| 9 | + - Modules belonging to executables were being built in too many ways. For instance, if you |
| 10 | + had configured to build profiled library files then your executable modules would also |
| 11 | + be built profiled. Which was a regression in behaviour since `Cabal-3.12`. |
| 12 | + |
| 13 | +- Fix ./setup install command [#10416](https://github.com/haskell/cabal/issues/10416) [#10417](https://github.com/haskell/cabal/pull/10417) |
| 14 | + |
| 15 | + - `./setup install` was failing with a `fromFlag NoFlag` error. It is now fixed. |
| 16 | + |
| 17 | +- Neutral field to add files to sdist [#8817](https://github.com/haskell/cabal/issues/8817) [#10107](https://github.com/haskell/cabal/pull/10107) |
| 18 | + |
| 19 | + Adds the `extra-files` field to the cabal file specification. This is like |
| 20 | + the other `extra-*` fields in that it is copied with the `sdist` command, |
| 21 | + except there are no other semantics. Compare to: |
| 22 | + |
| 23 | + * `extra-source-files`: Tracked by `cabal build`. |
| 24 | + |
| 25 | + * `extra-doc-files`: Copied by Haddock to the html directory. |
| 26 | + |
| 27 | +### Other changes |
| 28 | + |
| 29 | +- Add new options from ghc 9.12 [#10468](https://github.com/haskell/cabal/pull/10468) |
| 30 | + |
| 31 | + - ghc 9.12 adds several new command line options, divided between |
| 32 | + `LANGUAGE`s (already added), warnings, new preprocessor control options, |
| 33 | + and compilation control options. Two options needed to be added to the |
| 34 | + list of options requiring `Int` parameters. |
| 35 | + |
| 36 | + The new options, excluding warning and language options, are: |
| 37 | + |
| 38 | + * `-fexpose-overloaded-unfoldings` |
| 39 | + * `-fmax-forced-spec-args=N` |
| 40 | + * `-fno-expose-overloaded-unfoldings` |
| 41 | + * `-fno-object-determinism` |
| 42 | + * `-fobject-determinism` |
| 43 | + * `-fwrite-if-compression=N` |
| 44 | + * `-optCmmP…` |
| 45 | + * `-optJSP…` |
| 46 | + * `-pgmCmmP` |
| 47 | + * `-pgmJSP` |
| 48 | + |
| 49 | + As they all affect compilation and store hashes, the only necessary |
| 50 | + change was to list the two numeric options so they will be parsed |
| 51 | + correctly. To the best of our understanding, `-pgm*` and `-opt*` |
| 52 | + options are already handled as a group. |
| 53 | + |
| 54 | +- Include package version when passing `--promised-dependency` flag [#10166](https://github.com/haskell/cabal/issues/10166) [#10248](https://github.com/haskell/cabal/pull/10248) |
| 55 | + |
| 56 | + The `--promised-dependency` flag now expects an argument in the format |
| 57 | + |
| 58 | + ``` |
| 59 | + NAME-VER[:COMPONENT_NAME]=CID |
| 60 | + ``` |
| 61 | + |
| 62 | + rather than |
| 63 | + |
| 64 | + ``` |
| 65 | + NAME[:COMPONENT_NAME]=CID |
| 66 | + ``` |
| 67 | + |
| 68 | +- Add support for building profiled dynamic way [#4816](https://github.com/haskell/cabal/issues/4816) [#9900](https://github.com/haskell/cabal/pull/9900) |
| 69 | + |
| 70 | + Add support for profiled dynamic way |
| 71 | + |
| 72 | + New options for `cabal.project` and `./Setup` interface: |
| 73 | + |
| 74 | + * `profiling-shared`: Enable building profiling dynamic way |
| 75 | + * Passing `--enable-profiling` and `--enable-executable-dynamic` builds |
| 76 | + profiled dynamic executables. |
| 77 | + |
| 78 | + Support for using `profiling-shared` is guarded behind a constraint |
| 79 | + which ensures you are using `Cabal >= 3.13`. |
| 80 | + |
| 81 | + In the cabal file: |
| 82 | + |
| 83 | + * `ghc-prof-shared-options`, for passing options when building in |
| 84 | + profiling dynamic way |
| 85 | + |
| 86 | +- Working directory support for `Cabal` [#9702](https://github.com/haskell/cabal/issues/9702) [#9718](https://github.com/haskell/cabal/pull/9718) |
| 87 | + |
| 88 | + The `Cabal` library is now able to handle a passed-in working directory, instead |
| 89 | + of always relying on the current working directory of the parent process. |
| 90 | + |
| 91 | + In order to achieve this, the `SymbolicPath` abstraction was fleshed out, and |
| 92 | + all fields of `PackageDescription` that, if relative, should be interpreted |
| 93 | + with respect to e.g. the package root, use `SymbolicPath` instead of `FilePath`. |
| 94 | + |
| 95 | + This means that many library functions in `Cabal` take an extra argument of type |
| 96 | + `Maybe (SymbolicPath CWD (Dir "Package"))`, which is an optional (relative or |
| 97 | + absolute) path to the package root (if relative, relative to the current working |
| 98 | + directory). In addition, many functions that used to manipulate `FilePath`s now |
| 99 | + manipulate `SymbolicPath`s, require explicit conversion using e.g. `getSymbolicPath`. |
| 100 | + |
| 101 | + To illustrate with file searching, the `Cabal` library defines: |
| 102 | + |
| 103 | + ```haskell |
| 104 | + findFileCwd |
| 105 | + :: forall dir1 dir2 file |
| 106 | + . Verbosity |
| 107 | + -> Maybe (SymbolicPath CWD (Dir dir1)) |
| 108 | + |
| 109 | + -> [SymbolicPath dir1 (Dir dir2)] |
| 110 | + |
| 111 | + -> RelativePath dir2 File |
| 112 | + |
| 113 | + -> IO (SymbolicPath dir1 File) |
| 114 | + ``` |
| 115 | + |
| 116 | + See Note [Symbolic paths] in `Distribution.Utils.Path` for further information |
| 117 | + on the design of this API. |
| 118 | + |
| 119 | +- Add `MultilineStrings` extension (GHC proposal #637) [#10245](https://github.com/haskell/cabal/pull/10245) |
| 120 | + |
| 121 | +- Add `NamedDefaults` extension (GHC proposal #409) [#9740](https://github.com/haskell/cabal/pull/9740) |
| 122 | + |
| 123 | +- Add `OrPatterns` extension (GHC proposal #958) [#10339](https://github.com/haskell/cabal/pull/10339) |
| 124 | + |
| 125 | + |
| 126 | +### Other changes |
| 127 | + |
| 128 | +- Add flag `--ignore-build-tools` [#10128](https://github.com/haskell/cabal/pull/10128) |
| 129 | + |
| 130 | + - Adds flag `--ignore-build-tools` which allows a user to ignore the tool |
| 131 | + dependencies declared in `build-tool-depends`. For general use, this flag |
| 132 | + should never be needed, but it may be useful for packagers. |
| 133 | + |
| 134 | +- Do not try to build dynamic executables on Windows [#10217](https://github.com/haskell/cabal/pull/10217) |
| 135 | + |
| 136 | + - Cabal will now exit with a descriptive error message instead of attempting to |
| 137 | + build a dynamic executable on Windows. |
| 138 | + |
| 139 | +- Always pass `ghc-options` to GHC [#8717](https://github.com/haskell/cabal/pull/8717) |
| 140 | + |
| 141 | + Previously, options set in the package field `ghc-options` would not be passed |
| 142 | + to GHC during the link phase for shared objects (where multiple `.o` or |
| 143 | + `.dyn_o` files are merged into a single object file). This made it impossible |
| 144 | + to use `ghc-options` to use a different linker by setting (for example) |
| 145 | + `ghc-options: -optl-fuse-ld=mold -optlm-fuse-ld=mold`; the options would be |
| 146 | + dropped in the link phase, falling back to the default linker. |
| 147 | + |
| 148 | + It was possible to work around this by duplicating the `ghc-options` to |
| 149 | + `ghc-shared-options`, which _are_ passed in the shared link phase, but that had |
| 150 | + the undocumented and unfortunate side-effect of disabling the GHC |
| 151 | + `-dynamic-too` flag, effectively doubling compilation times when |
| 152 | + `ghc-shared-options` are set. |
| 153 | + |
| 154 | + Now, `ghc-options` are combined with `ghc-shared-options` (to accurately |
| 155 | + reflect the documentation on this feature) and the fact that |
| 156 | + `ghc-shared-options` disables `-dynamic-too` is documented. |
| 157 | + |
| 158 | +- Introduce `SetupHooks` [#9551](https://github.com/haskell/cabal/pull/9551) |
| 159 | + |
| 160 | + Introduction of a new build type: `Hooks`. |
| 161 | + This build type, intended to eventually replace the `Custom` build type, integrates |
| 162 | + better with the rest of the ecosystem (`cabal-install`, Haskell Language Server). |
| 163 | + |
| 164 | + The motivation and full design of this new build-type are specified in the |
| 165 | + Haskell Foundation Tech Proposal |
| 166 | + [Replacing the Cabal Custom build-type](https://github.com/haskellfoundation/tech-proposals/pull/60). |
| 167 | + |
| 168 | + Package authors willing to use this feature should declare `cabal-version: 3.14` and `build-type: Hooks` |
| 169 | + in their `.cabal` file, declare a `custom-setup` stanza with a dependency on the |
| 170 | + `Cabal-hooks` package, and define a module `SetupHooks` that exports a value |
| 171 | + `setupHooks :: SetupHooks`, using the API exported by `Distribution.Simple.SetupHooks` |
| 172 | + from the `Cabal-hooks` package. Refer to the Haddock documentation of |
| 173 | + `Distribution.Simple.SetupHooks` for example usage. |
| 174 | + |
| 175 | +- Redefine `build-type: Configure` in terms of `Hooks` [#9969](https://github.com/haskell/cabal/pull/9969) |
| 176 | + |
| 177 | + The `build-type: Configure` is now implemented in terms of `build-type: Hooks` |
| 178 | + rather than in terms of `build-type: Custom`. This moves the `Configure` |
| 179 | + build-type away from the `Custom` issues. Eventually, `build-type: Hooks` will |
| 180 | + no longer imply packages are built in legacy-fallback mode. When that |
| 181 | + happens, `Configure` will also stop implying `legacy-fallback`. |
| 182 | + |
| 183 | + The observable aspect of this change is `runConfigureScript` now having a |
| 184 | + different type, and `autoconfSetupHooks` being exposed by `Distribution.Simple`. |
| 185 | + The former is motivated by internal implementation details, while the latter |
| 186 | + provides the `SetupHooks` value for the `Configure` build type, which can be |
| 187 | + consumed by other `Hooks` clients (e.g. eventually HLS). |
| 188 | + |
| 189 | +- Cabal can issue a number of error messages referencing "Setup configure", |
| 190 | + but it simply references "configure" which could mean any of three |
| 191 | + things (Setup configure, the package's "configure" script, or "cabal |
| 192 | + configure"). This has recently caught out even Cabal devs. Clarify these |
| 193 | + messages. [#9476](https://github.com/haskell/cabal/pull/9476) |
| 194 | + |
| 195 | +- Update the SPDX License List to version 3.25 |
| 196 | + |
| 197 | + The LicenseId and LicenseExceptionId types are updated to reflect the SPDX |
| 198 | + License List version 3.25 (2024-08-19). |
0 commit comments