The reason for non-GHC boot dependencies

[Hécate]

For context, the move from xhtml to lucid2 is very much in progress, for 
both haddock and hpc. The necessity to avoid too many third-party 
libraries is that in its current (and very custom) setup, dependencies 
are git submodules in the GHC tree. Which somewhat make sense because 
these dependencies have sometimes to be adjusted when they use unstable 
internal APIs.

Le 10/07/2024 à 18:22, Artem Pelenitsyn 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.
>
> There once was a sizeable patch to Haddock to switch from xhtml to Lucid,
> and it was rejected, seemingly, solely on the grounds that Lucid can't 
> be added to boot libraries [1].
> Since then Lucid dropped the heavier part of its dependency tree, so 
> it's maybe not an issue anymore,
> but my point is that there's more to this story than what you 
> mentioned: the need for keeping Haddock and HPC's
> dependencies in the set of boot libraries may slow down development of 
> those tools.
>
> [1]: https://github.com/haskell/haddock/pull/1598#issuecomment-1621765685
>
> On Wed, Jul 10, 2024 at 12:10 PM Andreas Klebinger via ghc-devs 
> <ghc-devs at haskell.org> wrote:
>
>     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
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240710/91ff3a25/attachment.html>