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@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
--
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