The reason for non-GHC boot dependencies

[Hécate]

Ah, that is a much better explanation for the distribution of shared 
libraries, thank you very much Matthew!

I am not sure however that I follow your reasoning that we might as well 
expose them, but this is not a hill I am ready to die on right now. :)

Have a nice day and thank you for the clarification!

Hécate

Le 11/07/2024 à 10:41, Matthew Pickering a écrit :
> 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

-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD