<div dir="ltr"><div><div>Hi everyone, here are the minutes of today's meeting:</div></div><div><br></div><div>## 3.10.2.0 Release</div><div><br></div><div>The release has been cut and we will dogfood it for a short while. The binaries are uploaded at <a href="https://downloads.haskell.org/~cabal/Cabal-3.10.2.0/">https://downloads.haskell.org/~cabal/Cabal-3.10.2.0/</a> and are being integrated into ghcup.</div><div><br></div><div>An official announcement will be sent on October 9th, along with the GHC 9.8 release. You are encouraged to try it out. Each archive contains a binary and the plan file generated by the build system.</div><div><br></div><div>## Bad paths on Windows</div><div><br></div><div><a href="https://github.com/haskell/cabal/issues/9253">https://github.com/haskell/cabal/issues/9253</a> has been merged, although short of replacing FilePath with OsPath, there will always be the possibility of other problems.</div><div><br></div><div>## Setup.hs</div><div><br></div><div>The effort to give a better alternative to custom Setup.hs is reviving. The problematic generality of the current mechanism is the main source of pain. This produces much complexity (as in "it is hard to determine outputs from known inputs").</div><div><br></div><div>## Misc</div><div><br></div><div>Hécate: It would be nice to take some time and think about how GHC and cabal have evolved during the last decades, and how with the consolidation of the ecosystem, different boundaries could be drawn. Some code paths and concerns could migrate from one tool to the other.</div><div><br></div><div> Ben: We have a cabal specification; I wish we'd kept that up to date; I think that would define the interface between cabal & ghc and other
implementations.</div><div>Gershom: Code as spec would be a good solution.</div><div><br></div><div>Hécate will probably spend some time on refitting the dump-decls tool made for GHC release engineering to something more standalone (perhaps integrated in cabal-install?)<br></div></div>