The reason for non-GHC boot dependencies

[Matthew Pickering]

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 at 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 at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs