On Mon, May 25, 2020 at 2:52 PM Matthias Kilian <kili@outback.escape.de> wrote:
> > I know why GHC behaves this way, but this property turns minor updates
> > into major events.
>
> Should we do an experiment and try to get rid of MODGHC_PACKAGE_KEY?
I expect we'd trade an obvious and quick failure for a delayed and
insidious one :(
> That would be one sweep over all hs-ports, which I could do on a
> weekend.
>
> The risk would be that the old behaviour strikes back, i.e. some
> stupid constant somewhere changes and causes symbol name changes
> in hs-libraries. For example, in the past, changing the build date
> of the ghc bootstrapper was enough to cause symbol name changes in
> ghc's libs (IIRC that was the reason why I initially introduced
> that MODGHC_PACKAGE_KEY).
I'm warming up more and more to doing a "shallow" embedding of Haskell binary
packages. I recently figured out how to package up [cabal-install] with a simple
port that builds all its dependencies inside. It's slow, but not
prohibitively so.
[cabal-install]:
https://github.com/blackgnezdo/ports/commit/2a7ce5c0e47a0e011b3dfb9a0437897cca0f641a
Thanks
Greg
--
nest.cx is Gmail hosted, use PGP: https://pgp.key-server.io/0x0B1542BD8DF5A1B0
Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0
No comments:
Post a Comment