Haddock is not migrated yet to only require interface files. Sjoerd Visscher has been working on this recently.
On Thu, Jul 11, 2024 at 10:28 AM Michael Peyton Jones <m...@michaelpj.com> wrote: > > > The `haddock` executable must be dynamically linked as it must compile > source files. > > Is this still true in the post-hi-haddock world? I thought we removed the > code path in cabal that needed that, so recent versions of haddock shouldn't > need it either? > > M > > On Thu, Jul 11, 2024 at 9:41 AM Matthew Pickering > <matthewtpicker...@gmail.com> wrote: >> >> The `haddock` executable must be dynamically linked as it must compile >> source files. It is much more robust to use dynamic linking when >> loading dependencies for TH evaluation than static linking. HLS is >> dynamically linked for the same reason. >> >> As such we have to distribute at least shared libraries for >> dependencies for haddock etc. It seems therefore that we might as well >> advertise these libraries are available in the package database. The >> things that we definitely have to advertise in the package database >> are `Cabal` and `ghc` and dependencies. >> >> The point about which libraries are boot libraries is a separate one. >> If you are developing a library which is a boot library then you are >> restricted to a small set of dependencies. Additional dependencies >> introduce a large amount of friction due to the coordindation needed >> during a release process. Anyone is free to develop their own >> libraries which use whichever dependencies they wish in user-space. >> >> Cheers, >> >> Matt >> >> On Wed, Jul 10, 2024 at 5:55 PM Hécate via ghc-devs >> <ghc-devs@haskell.org> wrote: >> > >> > Thanks a lot for the clarification Andreas. >> > >> > So, the present situation is that we seem to have an implicit set of >> > packages that are readily available to users of ghc and ghci, but which >> > serve no direct goal for the end-user, and whose presence is fairly >> > arbitrary. >> > >> > In light of the recent discussions about the mental model of >> > dependencies, cabal and GHC, I was wondering if anything was keeping us >> > expose these packages the user does not explicitly download. >> > >> > I will take some time to see how to switch to (haskell-)static linking >> > for distribution releases. >> > >> > Have a nice day, >> > >> > Hécate >> > >> > Le 10/07/2024 à 18:10, Andreas Klebinger via ghc-devs a écrit : >> > > I think they could be statically linked. But those boot libraries don't >> > > change much and generally >> > > don't really cause us nor users pain so it seems like there is little >> > > reason to do so to me. >> > > >> > > > Surely the size of binaries can't be the only concern, otherwise we'd >> > > use upx¹ on them when distributing them. >> > > >> > > I believe Ben experimented with executable compression tools in the past >> > > with little success. >> > > But there were segfaults, executables being flagged by antivirus and >> > > perhaps more issues I forgot >> > > which just made using it unrealistic at the time. >> > > >> > > But perhaps the tooling has matured in the meantime. >> > > >> > > Since our distributions are already compressed purely for *distribution* >> > > purposes I would expect the gains there to be rather slim anyway. >> > > >> > > So it's not really that we don't care about size, just that these tools >> > > seemed not reliable enough for the benefits they offer in the past. >> > > >> > > Am 10/07/2024 um 11:01 schrieb Hécate via ghc-devs: >> > >> Hi devs, >> > >> >> > >> I had a chat earlier today with someone and found myself unable to >> > >> explain the reason why GHC came with boot dependencies like xhtml, >> > >> that are dependencies of Haddock and HPC. >> > >> >> > >> Obviously, the binaries are (haskell-)dynamically linked when >> > >> distributed, but what is the reason why haddock, hpc, etc can't be >> > >> (haskell-)statically linked when distributed? >> > >> >> > >> Surely the size of binaries can't be the only concern, otherwise we'd >> > >> use upx¹ on them when distributing them. >> > >> >> > >> Cheers, >> > >> >> > >> Hécate >> > >> >> > >> >> > >> 1: https://upx.github.io >> > >> >> > > _______________________________________________ >> > > ghc-devs mailing list >> > > ghc-devs@haskell.org >> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >> > -- >> > Hécate ✨ >> > 🐦: @TechnoEmpress >> > IRC: Hecate >> > WWW: https://glitchbra.in >> > RUN: BSD >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs@haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
